- Is this safe? - 3 Updates
- strange error (QT Creator 4.12.2, based on QT creator 5.14.2) - 1 Update
- A new design pattern, the "template mixin" - 1 Update
- Found a use case for `const` by value return, a shared queue - 13 Updates
- lista inicjalizacyjna - pytanie - 1 Update
| Malcolm McLean <malcolm.arthur.mclean@gmail.com>: Mar 03 08:16PM -0800 On Friday, 3 March 2023 at 21:45:09 UTC, Ben Bacarisse wrote: > I think you are talking about what I once referred to as > Malcolm-functions. Unfortunately I don't remember enough about what you > mean by the term to do anything but agree with the consequent. A Malcolm function is that subset of mathematical functions which can be implemented by programming languages. A mathematical function is a mapping from an input set to an output set such that for every member of the input set there is one and only member of the output set. Since Malcolm functions are programming entities, the input set has to ultimately be bits, and the output set also ultimately has to be bits. So bits on function entry determines bits on function exit. Unlike "pure functions" there are no special syntactical or data hiding requirement on Malcolm functions. To all intents and purposes, the term is identical in meaning to the term "function", used in the accepted sense in a computer context, not in the C sense to mean "subroutine". |
| "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu>: Mar 04 06:47AM -0800 > >> always crash which isn't necessarily the case depending on what machine i= > >ts=20 > >> running on. ... > Whooosh.... That's a useless response. Let me simplify my answer in the hopes of provoking a more useful response. He did not in any way assume that it will always crash. He, in fact, said absolutely nothing about crashing. He only claimed that it had no defined behavior. Since you claim he made that assumption, please explain what led you to that false conclusion. |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Mar 04 10:55PM > the term is identical in meaning to the term "function", used in the > accepted sense in a computer context, not in the C sense to mean > "subroutine". I don't know what bits are involved. You can't mean just the bits in the parameter and return values or int func() { getchar(); return 10; } would be a Malcolm function, and you can't mean all the bits in the entire (virtual) system or the specification for such a function would be ridiculous. -- Ben. |
| MarioCPPP <NoliMihiFrangereMentulam@libero.it>: Mar 04 10:53PM +0100 On 03/03/23 18:29, Keith Thompson wrote: > required. For example, 32-bit x86 systems typically use 4-byte > alignment for 8-byte integers. For most purposes, you as a programmer > don't need to know the alignment requirements for integer types; the same should hold true when you manually cast pointers to and fro different types ? Maybe yes, I dunno, in the doubt I thought aligning to the most restrictive would have been prudent. But I had chosen the wrong command (static_cast, which does more than I supposed, and I replaced it with reinterpret_cast) -- 1) Resistere, resistere, resistere. 2) Se tutti pagano le tasse, le tasse le pagano tutti MarioCPPP |
| Mr Flibble <flibble@reddwarf.jmc.corp>: Mar 04 07:24PM Here is an example of a C++ "template mixin", whereby interfaces are related by inheritance in a way that is covariant to the relationship between the abstract and concrete classes that implement them. This new pattern is compatible with the object oriented SOLID principles and is a way of using single inheritance to avoid the problems associated with multiple inheritance. Here the interface classes (denoted by the i_ prefix) are implemented by the template mixin and the concrete class that derives from it. Note: inheritance relationships being modeled here are of the "is-a" kind. struct i_foo { virtual void m1() = 0; }; struct i_bar : i_foo { virtual void m2() = 0; } template <typename base = i_foo> struct foo : base { void m1() final { /*...*/ } }; struct bar : foo<i_bar> { void m2() final { /*...*/ } } /Flibble |
| Bonita Montero <Bonita.Montero@gmail.com>: Mar 04 05:38AM +0100 Am 03.03.2023 um 21:45 schrieb Chris M. Thomasson: > Not until you model it in something like Relacy. > No time right now to read all of your code and verify it. Sorry, the code is trivial from the MT-perspective. |
| Muttley@dastardlyhq.com: Mar 04 09:53AM On Fri, 3 Mar 2023 19:51:19 +0100 >Use this thread-queue: No thanks. Life's too short to figure out what its doing but a thread queue should be a couple of lines of code. |
| Bonita Montero <Bonita.Montero@gmail.com>: Mar 04 03:38PM +0100 > Life's too short to figure out what its doing but a thread queue should be > a couple of lines of code. Show me your code then I show your mistakes and your less to convenient to use code. Except from the used concepts the code is straitforward. |
| Muttley@dastardlyhq.com: Mar 04 03:28PM On Sat, 4 Mar 2023 15:38:24 +0100 >Show me your code then I show your mistakes and your less to >convenient to use code. Except from the used concepts the code >is straitforward. #include <unistd.h> #include <iostream> #include <thread> #include <mutex> #include <deque> #include <condition_variable> using namespace std; mutex mt; condition_variable cv; void func(int id) { unique_lock<mutex> ul(mt); cout << "Thread " << id << " waiting.\n"; cv.wait(ul); cout << "Thread " << id << " started.\n"; } int main() { deque<thread> dq; for(int i=0;i < 10;++i) dq.push_back(thread(func,i)); sleep(1); cv.notify_all(); for(auto &thr: dq) thr.join(); return 0; } |
| Bonita Montero <Bonita.Montero@gmail.com>: Mar 04 05:17PM +0100 > for(auto &thr: dq) thr.join(); > return 0; > } * This isn't a reusable component. * Why are you using a deque for the threads and not for the items you enqueue themselfes ? For the threads a vector<> would be more convenient to use and if you have a reserve() on it before creating the threads this would be slightly more efficient. * You're using a wait which can't handle spurious wakeups. * sleep() doesn't make sense here and it isn't C++; you should use this_thread::sleep_for() if you do it at all. * You could use jthreads and strip the .join()s. That's not professional programming. |
| Muttley@dastardlyhq.com: Mar 04 04:21PM On Sat, 4 Mar 2023 17:17:02 +0100 >> return 0; >> } >* This isn't a reusable component. Why not? You can take the core bits out and put them anywhere. >* Why are you using a deque for the threads and not for the items > you enqueue themselfes ? For the threads a vector<> would be more You wanted a queue, you got a queue. > convenient to use and if you have a reserve() on it before creating > the threads this would be slightly more efficient. Wow, really? Thanks for the heads up there. >* You're using a wait which can't handle spurious wakeups. Its a simple example. >* sleep() doesn't make sense here and it isn't C++; you should use It does make sense, it's a standard unix API call and I don't need to use sleep_for. >* You could use jthreads and strip the .join()s. "Oh look at me, I can quote obscure parts of C++20 to try and look clever!" >That's not professional programming. Its perfectly fine as example code and far more intelligable that your overcomplicated load of show off bollocks. |
| Bonita Montero <Bonita.Montero@gmail.com>: Mar 04 05:39PM +0100 > Why not? You can take the core bits out and put them anywhere. A reusable component is sth. like mine where you won't have to deal with all the details. >> * Why are you using a deque for the threads and not for the items >> you enqueue themselfes ? For the threads a vector<> would be more > You wanted a queue, you got a queue. Yes, but a queue with data shared among the threads. A queue of threads doesn't make sense. >> * You're using a wait which can't handle spurious wakeups. > Its a simple example. It doesn't work reliably because of what I said. You might have spurious wakeups, i.e. wakeups which occur although nothong happened on the sender side; that's documented C++-behaviour. > It does make sense, it's a standard unix API call and I don't need to use > sleep_for. If you have a producer-consumer-pattern you don't sleep(), even not with C++-means. >> * You could use jthreads and strip the .join()s. > "Oh look at me, I can quote obscure parts of C++20 to try and look clever!" The language becomes increasingly more convenient to to use with newer versions; jthread is one aspect of that. >> That's not professional programming. > Its perfectly fine as example code and far more intelligable that your > overcomplicated load of show off bollocks. Idiot. |
| Muttley@dastardlyhq.com: Mar 04 04:57PM On Sat, 4 Mar 2023 17:39:05 +0100 >> Why not? You can take the core bits out and put them anywhere. >A reusable component is sth. like mine where you won't have to deal >with all the details. sth? Understanding your overcomplicated code is a detail in itself. >> You wanted a queue, you got a queue. >Yes, but a queue with data shared among the threads. >A queue of threads doesn't make sense. Well fair enough. In which case something like this. T consumer() { mtx.lock(); auto whatever = dq.pop_front(); mtx.unlock(); return whatever; } Similar code for popping it in to the q. >It doesn't work reliably because of what I said. You might have >spurious wakeups, i.e. wakeups which occur although nothong happened >on the sender side; that's documented C++-behaviour. So pass wait() a lambda that checks a flag so see if something did happen. >> sleep_for. >If you have a producer-consumer-pattern you don't sleep(), even not with >C++-means. As I said you muppet, it was example code. The sleep is so you can see what is going on. Also FYI sleep() only affects the thread its called from so it simply pauses the main thread until all the threads are set up. >> "Oh look at me, I can quote obscure parts of C++20 to try and look clever!" >The language becomes increasingly more convenient to to use with newer >versions; jthread is one aspect of that. It avoids a single call to detach(). A valuable addition to the language. Not. >> Its perfectly fine as example code and far more intelligable that your >> overcomplicated load of show off bollocks. >Idiot. Truth hurt? |
| Bonita Montero <Bonita.Montero@gmail.com>: Mar 04 06:06PM +0100 >> A reusable component is sth. like mine where you won't have to deal >> with all the details. > Understanding your overcomplicated code is a detail in itself. Understanding all what a unordered_map is also complicated. But you only have to understand the the interface. > mtx.unlock(); > return whatever; > } This also doesn't work because you don't test if there are items inside the queue. >> spurious wakeups, i.e. wakeups which occur although nothong happened >> on the sender side; that's documented C++-behaviour. > So pass wait() a lambda that checks a flag so see if something did happen. F.e.. >> If you have a producer-consumer-pattern you don't sleep(), even not with >> C++-means. > As I said you muppet, it was example code. ... Even for example code you don't need a wait(). >> The language becomes increasingly more convenient to to use with newer >> versions; jthread is one aspect of that. > It avoids a single call to detach(). A valuable addition to the language. Not. If you'd detach returning from main() and ending the program could occur earlier than any threads would complete. There's no guarantee that your runtime waits on detached threads. |
| Bonita Montero <Bonita.Montero@gmail.com>: Mar 04 06:10PM +0100 Am 04.03.2023 um 18:06 schrieb Bonita Montero: > If you'd detach returning from main() and ending the program could occur > earlier than any threads would complete. There's no guarantee that your > runtime waits on detached threads. F.e. this prints nothing on my Windows- and Linux-PC: #include <iostream> #include <thread> using namespace std; int main() { thread( []() { cout << "hello world" << endl; } ).detach(); } |
| Muttley@dastardlyhq.com: Mar 04 05:14PM On Sat, 4 Mar 2023 18:06:47 +0100 >> } >This also doesn't work because you don't test if there are items >inside the queue. Fine, do a check on the same line and make the return value an optional or a pointer or a pair with a bool flag or 101 other ways of notifying the caller when there's nothing available. Either way, its still only a few lines of simple code unlike yours. >>> on the sender side; that's documented C++-behaviour. >> So pass wait() a lambda that checks a flag so see if something did happen. >F.e.. No idea what that means. >>> C++-means. >> As I said you muppet, it was example code. ... >Even for example code you don't need a wait(). Have you ever used condition variables? >If you'd detach returning from main() and ending the program could occur >earlier than any threads would complete. There's no guarantee that your >runtime waits on detached threads. There is that, but its hardly important. If you main thread exits then you almost certainly don't care what any detached threads are doing at that point anyway. |
| Bonita Montero <Bonita.Montero@gmail.com>: Mar 04 06:41PM +0100 >> This also doesn't work because you don't test if there are items >> inside the queue. > Fine, do a check .... You said that you would give an example. But it doesn't work for a few reasons. > Have you ever used condition variables? Check my code, it uses a CV. >> earlier than any threads would complete. There's no guarantee that your >> runtime waits on detached threads. > There is that, but its hardly important. ... For your example code it would be. |
| Bonita Montero <Bonita.Montero@gmail.com>: Mar 04 08:07PM +0100 Am 04.03.2023 um 18:41 schrieb Bonita Montero: >>> runtime waits on detached threads. >> There is that, but its hardly important. ... > For your example code it would be. My code looks like f.e. like this: thread_queue<string> stringQueue; ... stringQueue.enqueue( "hello world" ); ... string dequeued( stringQueue.dequeue() ); That's all. |
| Muttley@dastardlyhq.com: Mar 04 09:52AM On Fri, 3 Mar 2023 21:50:43 +0100 >> tuleks initsialiseerimiseks kasutada initsialiseerijate loendit, selle >> jaoks on see mõeldud. >I can't read the Finish one Google translate is a very useful tool: In the case of the given example, it doesn't really matter which one to use, but in general a list of initializers should be used for initialization, this it is intended for. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment