- "C++20 Coroutines" by Martin Bond - 5 Updates
- rational numbers - 3 Updates
- Memory allocator - 2 Updates
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 24 06:15PM +0200 Am 23.09.2021 um 11:05 schrieb Branimir Maksimovic: >> No, that's much less clearer than having a state like you're in a normal >> function. > coroutines are just same thing as threads ... No, they're similar to fiberes - with much less overhead. |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 24 06:17PM +0200 >> No, that's much less clearer than having a state like you're in a normal >> function. > That is a matter of opinion. That's not a matter of opinion. If you've managed to write a complex sate-machine you honor the convenience and readability of coroutines. |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 24 06:19PM +0200 Am 23.09.2021 um 09:42 schrieb Juha Nieminen: > No, yielding precisely *avoids* spaghetti code, ... State-machines are _always_ spahgetti-code (while( !end ) switch( state ) { ... }), even when you write them conventionally. But coroutines are _much_ more readable and maintainable. |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Sep 24 09:07PM +0100 > State-machines are _always_ spahgetti-code (while( !end ) > switch( state ) { ... }), even when you write them conventionally. Obviously one person's spaghetti is another person's farfalle, but in my opinion, if the state is a (a pointer to a) function that returns (a pointer to) the next state, then you just get a clean loop calling a function: data d = { ... }; State state = initial; while (state) state = (State)state(&d); C++ has trouble writing the recursive type, so you need a cast, but it's a safe cast. -- Ben. |
| Sam <sam@email-scan.com>: Sep 24 07:21PM -0400 Juha Nieminen writes: > You seem to have a strange misconception that coroutines are nothing > but simulating multithreading in a single-threaded program. > They are aren't. And I never said they are. They are not a simulation of multithreading. They're a failed simulation of multithreading, on a platform with a rather bad native implementation of multiple execution threads. |
| "daniel...@gmail.com" <danielaparker@gmail.com>: Sep 24 09:21AM -0700 On Thursday, September 23, 2021 at 8:59:02 PM UTC-4, Bart wrote: > If you are reading CSV files and such, fields are sometimes enclosed in > quotes, including numeric fields. I don't think anybody would attempt to read a CSV file with `<istream> >> field1 >> field2 >> field3` notation. But of course line oriented input wouldn't be of much help here either, in general. As to a number enclosed in quotes, I think a typical CSV parser would by default interpret that as string, but perhaps provide an option to interpret a quoted value in a specified column as a number. Daniel |
| Bart <bc@freeuk.com>: Sep 24 05:25PM +0100 >> it converts the string to "%d %f". There is zero impact on any binaries. > And what happens if 'i' is a char? Do you want %c, %d or %u? What if its a > pointer? Do you want %p, %x, %X, %lu etc? In C, char types count as integers. My scheme only takes care of the /types/ of the expression (so that you don't to choose from %d %lld PRIi64 etc). If you want a different textual representation, that's when you need to be explicit. My experimental feature generates one of %d %u %lld %llu %f %s %p. %s is used for char* types, and %p for other pointers. With this program: int main(void) { int a=10; unsigned int b=20; long long int c=30; unsigned long long int d=40; double e=50.1; char* f="sixty"; void* g=&a; void(*h)(void)=main; printf("%? %? %? %? %? %? %? %?\n", a, b, c, d, e, f, g, h); } the format string is changed to: "%d %u %lld %llu %f %s %p %p\n" The output is: 10 20 30 40 50.100000 sixty 000000000080FF48 0000000000401000 At this point, with this enhancement, C's printf (I know it's in C++ too) looks better than: std::cout << a << " " << b << " " << c << " " << d << " " << e << " " << f << " " << g << " " << h << "\n"; But remember that in my kiddies' language, it's still just: println a, b, c, d, e, f, g, h And still totally unprofessional, of course. (Maybe a professional wouldn't be able to claim so many hours' pay if the language was too easy!) > So you're complaining about basic C++ functionality you don't even understand. > Got it. Would understanding it make me happier about typing out all that << nonsense above? >> rather than: >> ... A << " " << B ... > Whats special about a space? Have a look at the English written in these posts; what's the common separator between words? Yep, it's a single space. Handy for stopping alphanumeric entities from running into each other. Because of course, when you generate human readable text from a programming language, the most sensible default is to end up with: 12345678910 instead of: 1 2 3 4 5 6 7 8 9 10 > What if someone wants 2 spaces as a seperator > or maybe a tab or comma? C++ is a professional language, its not BASIC for > kiddies to output simple tabular results. So 'professional' equals 'unnecessarily complicated and unintuitive'? I think everyone's got that about C++! > What if someone wants 2 spaces as a seperator > or maybe a tab or comma? You make the most common, most useful and convenient requirement the default. Anything different, then that's when you have special code. Such as using formatted printing. In my book that's better than HAVING to write '<< " " <<' 99 times out of hundred, instead of nothing. > Plus a comma already has syntactic > meaning in C & C++. In programming languages it is very commonly used to separate the elements of a list. So why not the list of expressions in a print statement (or whatever std::cout << is classed as). >> Negative numbers aren't that difficult actually... > So long as you remember chars,ints etc are 2's complement whereas floating > point uses a sign bit. Yeah, thanks. |
| Paavo Helde <myfirstname@osa.pri.ee>: Sep 24 10:49PM +0300 > It's inherently inefficient though, particularly as it's frequently used to append a > small piece of text to a larger string, repeated many times. Thus are many > copies created. Memory copy is very cheap nowadays. And std::string::append() grows the buffer in the same way as std::vector::push_back, i.e. the complexity of growing a large string piecewise is amortized constant. |
| "Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Sep 24 06:55PM +0200 On 24 Sep 2021 16:58, Scott Lurndal wrote: > (dso) can use the strong version if it wishes to prevent the > application from overriding its malloc function. > (or read, or write, or lseek, etc). Well, that's something else (e.g. it won't affect calls to `malloc` from `operator new`, and it only supports the app overriding, not the library overriding), but I learned something. Thanks. :) - Alf |
| scott@slp53.sl.home (Scott Lurndal): Sep 24 05:23PM >Well, that's something else (e.g. it won't affect calls to `malloc` from >`operator new`, and it only supports the app overriding, not the library >overriding), but I learned something. Thanks. :) Wouldn't it be possible for the library to simply build its own allocator[*] and/or overload 'operator new' for the cases where it wants to control its own allocation? [*] Based on sbrk/mmap/whatever-windows-equivalent-exists-if-nay |
| 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