- Advent of Code 2020 - Spoiler day 03 part A - 7 Updates
- Member operators - why the restriction? - 1 Update
- Onwards and upwards - 2 Updates
- Safe calling of a coroutine function - 1 Update
| Juha Nieminen <nospam@thanks.invalid>: Dec 11 06:58AM > No, it just gets lost in a sea of :: That's the most ridiculous thing I have heard in a while. You could use the exact same argument to advocate for the removal of all parentheses, curly braces, brackets, semicolons, commas, hash symbols and so on and so forth. From all non-ascii characters that are used abundanty in C++ code, why are you singling out "::" in particular? From all the ones that exist, why those in particular? What's so special about those? |
| spuddy@isnotyourbuddy.co.uk: Dec 11 10:25AM On Fri, 11 Dec 2020 06:58:44 +0000 (UTC) >From all non-ascii characters that are used abundanty in C++ code, why >are you singling out "::" in particular? From all the ones that exist, >why those in particular? What's so special about those? I'm tired of this argument. Why can't Aspies like you understand that not everyone is the same or processes visual information in the same way. |
| Juha Nieminen <nospam@thanks.invalid>: Dec 11 11:33AM >>why those in particular? What's so special about those? > I'm tired of this argument. Why can't Aspies like you understand that not > everyone is the same or processes visual information in the same way. Ah, finally the insults. I'll take that as a concession of defeat. |
| spuddy@isnotyourbuddy.co.uk: Dec 11 02:34PM On Fri, 11 Dec 2020 11:33:35 +0000 (UTC) >> everyone is the same or processes visual information in the same way. >Ah, finally the insults. >I'll take that as a concession of defeat. Thank you for proving my point so emphatically. |
| Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk>: Dec 11 02:35PM >> Ah, finally the insults. >> I'll take that as a concession of defeat. > Thank you for proving my point so emphatically. You lost the argument, mate, I suggest you move on (and consider your irrationality whilst you are at it). /Flibble -- 😎 |
| spuddy@isnotyourbuddy.co.uk: Dec 11 04:43PM On Fri, 11 Dec 2020 14:35:52 +0000 >> Thank you for proving my point so emphatically. >You lost the argument, mate, I suggest you move on (and consider your >irrationality whilst you are at it). There is no argument "mate" because there's no right answer since its subjective not objective. Perhaps you lot should stop your circle jerking for 5 minutes and go look up the difference. |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Dec 11 06:14PM On Fri, 11 Dec 2020 10:25:01 +0000 (UTC) > >why those in particular? What's so special about those? > I'm tired of this argument. Why can't Aspies like you understand that not > everyone is the same or processes visual information in the same way. Ah, so you are the person who used to post as "Boltar". You were a juvenile nobody then, and still a juvenile nobody now. |
| Bonita Montero <Bonita.Montero@gmail.com>: Dec 11 09:40AM +0100 >> the object as the left operand. So you can' define a member operator >> with two parameters inside the class. > And your answer to "Why the restriction?" is... Because there's another place where to define such operators: globally. |
| Ian Collins <ian-news@hotmail.com>: Dec 11 01:55PM +1300 On 09/12/2020 20:58, David Brown wrote: > is yacc?). > There are also on-line services for generating code of various sorts. > In my line of work, I can think of two cases where I have used them. Most people needing serialisation will be using Google Protobuf or FlatBuffers, especially if, like us, they use multiple languages. The turnaround time to an online service would be longer then the time it takes to do the required generation. If you stand in front of a juggernaut, you will get flattened! -- Ian. |
| David Brown <david.brown@hesbynett.no>: Dec 11 09:05AM +0100 On 11/12/2020 01:55, Ian Collins wrote: > turnaround time to an online service would be longer then the time it > takes to do the required generation. > If you stand in front of a juggernaut, you will get flattened! Indeed. And when (I really hope it is "when", not "if") metaclasses get into the standard, we'll have serialisation as straight header-file libraries - there will be no need for code generators of any sort, at least for simple cases. Metaclasses will be the code generators. |
| Michael Podolsky <michpodolsky@gmail.com>: Dec 11 02:26AM -0500 I am looking for possible solutions to prevent some dangerous scenario (end developer bugs) in using C++ corotuines. Suppose we have an async function someFuture<int> receiveBuffer(char *buf, size_t size); and we further call it as int status = co_await receiveBuffer(buf, size); if(status== ok && strncmp(buf, "key", 3) { /* do something */ } all looks and works good until somebody writes a code like 1: receiveBuffer(buf, size); 2: if(strncmp(buf, "key", 3) { /* do something */ } Now, things are really bad. Not only that we did not check the status, but the worst thing - the line 2 is executed immediately without waiting for receiveBuffer function to complete. Things may get even more problematic if a coroutine function has no out parameters, but changes the state of a class (kind of side effect). class Job { // some private data public: SomeFuture<void> execute(const Params& ); void sendResults(); } compare now co_await job.execute(params) job.sendResults() and job.execute(params) job.sendResults() The second case again does not wait for the completion of the job and sendResults() may access data which is not yet ready. I need to find a way to prevent calling coroutines without awaiting for them. Better to prevent it in the time of compilation, catching that at runtime may be too late. Of course, to solve the egg and chicken problem, the first coroutine should be called without co_await, but for that I could consider some additional "launcher" function. Anyway, I cannot even see how the first problem may be solved in C++ - and that makes me think that C++ coroutines are very unsafe in the respect discussed above. Thanks in advance. |
| 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