- Is this safe? - 8 Updates
- Found a use case for `const` by value return, a shared queue - 2 Updates
- lvalue assignment difference between C and C++ - 3 Updates
- Order of addresses of string-literals inside a translation unit - 1 Update
| Andrey Tarasevich <andreytarasevich@hotmail.com>: Feb 21 10:32PM -0800 On 02/21/23 6:12 AM, Alf P. Steinbach wrote: > the type specification from the variable, i.e. `auto& c` not `auto &c`. > But on the third and gripping hand, in this case I'd write `char& c`, > since there's no advantage in `auto` here and it obscures things. Not really. This is a misleading "convention" that has no reason to exist. In this case the `&` is a part of an individual declarator, not a part of decl-specifier-seq. There's no reason to group the syntactic elements differently. It achieves nothing. -- Best regards, Andrey |
| Muttley@dastardlyhq.com: Feb 22 09:25AM On Tue, 21 Feb 2023 10:35:34 -0800 (PST) >obvious that you don't care about UTF-8, that you didn't consider the >possibility >that other people would consider that to be the most obvious safety concern. Absolute rubbish. Why would UTF8 have anything to do with "safety"? Safety means will the program crash or have hidden bugs, not whether a string gets translated into uppercase properly or not which would be immediately obvious. >The people who responded considered the resolution of the issue that you were >concerned with to be so obvious that they didn't even consider the possibility >that you were uncertain about it. Don't worry, next time I'll ask in crayon. |
| Muttley@dastardlyhq.com: Feb 22 09:26AM On Tue, 21 Feb 2023 10:58:31 -0800 (PST) >for >statement. If followed by a comma-delimited list of identifiers, i it would be >parsed as a structured binding declaration, and in that context & would be No it wouldn't. Whitespace is not significant in C++ (ok, apart from the > > vs >>) template syntax hack up until 2011. |
| Andrey Tarasevich <andreytarasevich@hotmail.com>: Feb 22 08:09AM -0800 > parsed as a structured binding declaration, and in that context & would be shared > by all of those identifiers, so it makes sense to separate it from them, and > combine it with the preceding specifiers, which they would also share. In a structured binding declaration it is not just a "comma-delimited list of identifiers". It is actually a []-enclosed comma-delimited list of identifiers (!). The presence of that `[]` is already perfectly sufficient to clearly convey the fact that the `&` applies to all identifiers in the list. Since a structured binding declaration always contains exactly one []-enclosed "declarator", the placement of spacing around `&` is moot. No reason to change the formatting rules from an ordinary declaration. Just keep aligning it to the right: `auto &[a, b]`. -- Best regards, Andrey |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Feb 22 08:32AM -0800 > exist. In this case the `&` is a part of an individual declarator, > not a part of decl-specifier-seq. There's no reason to group the > syntactic elements differently. It achieves nothing. I would say it achieves less than nothing, because it's misleading. It's like writing a+b * c ; the grouping suggested by the spacing doesn't match the actual precedence. In almost all cases it's a mistake to use "contra-syntactic" spacing, and attaching '&' or '*' to a type specifier is definitely one of those mistakes. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Feb 22 09:17AM -0800 > doesn't match the actual precedence. In almost all cases it's a > mistake to use "contra-syntactic" spacing, and attaching '&' or '*' > to a type specifier is definitely one of those mistakes. I prefer the "int *foo;" spacing (conventional in C) because it follows the syntax, but the "int* foo;" spacing has become a convention in C++ (probably because Stroustrup uses it in his books), and I use it in C++ for that reason. I also avoid declarations where it would make a difference to a human reader, like "int* foo, bar;". Most development is on existing code. It would be poor practice to use the "better" spacing on new code while leaving the existing code (which most likely uses the C++ conventional spacing) as it is. It would also be poor practice to change all the spacing in a large body of existing code. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for XCOM Labs void Void(void) { Void(); } /* The recursive call of the void */ |
| "Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Feb 22 10:33PM +0100 > Absolute rubbish. Why would UTF8 have anything to do with "safety"? Safety > means will the program crash or have hidden bugs, not whether a string gets > translated into uppercase properly or not which would be immediately obvious. The UB includes that the program can crash. >> concerned with to be so obvious that they didn't even consider the possibility >> that you were uncertain about it. > Don't worry, next time I'll ask in crayon. The sarcasm is well anchored in ignorance. - Alf |
| "Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Feb 22 10:34PM +0100 >> parsed as a structured binding declaration, and in that context & would be > No it wouldn't. Whitespace is not significant in C++ (ok, apart from the > > > vs >>) template syntax hack up until 2011. Either you missed the point, or you understood and deliberately snipped what you quoted to create a misleading impression. - Alf |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Feb 22 06:28AM -0800 >> I've looked at the raw input, before it ever gets processed by >> the newsreader. On most of the wrapped lines, no trailing spaces. > XRN doesn't "process" the message, it simply displays it as is. Surely displaying the message involves some processing, even if not very much. |
| scott@slp53.sl.home (Scott Lurndal): Feb 22 03:01PM >> XRN doesn't "process" the message, it simply displays it as is. >Surely displaying the message involves some processing, >even if not very much. const char *source_pointer = source; char *dest_pointer = dest; while (*source != '\0') *dest_pointer++ = *source_pointer++; I would call that moving the data, not processing the data. |
| Muttley@dastardlyhq.com: Feb 22 09:29AM On Tue, 21 Feb 2023 09:46:56 -0800 >> What does it do, assign `b` to `a` and immediately afterwards assign 2 to >`a`? >Yes. Wouldn't the compiler optimise this for primitive types where there will be no side effects from the assignment and simply assign 2 to both a and b directly? |
| "Öö Tiib" <ootiib@hot.ee>: Feb 22 01:46AM -0800 > Wouldn't the compiler optimise this for primitive types where there will be > no side effects from the assignment and simply assign 2 to both a and b > directly? No. Compilers I tried (if set to optimise) seem to do it same way. If `a` and `b` are further used then use constants 2 as `a` and 1 as `b` there. If those are not used then optimise all the posted code out totally. |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Feb 22 06:36AM -0800 > *`) and its direct derivatives (e.g. `[]` and `->`) are the only > operators that produce lvalue results. Everything else produces > rvalues. The dot operator ('.') propagates lvalueness. A compound literal expression gives an lvalue result. (Sorry if this posting seems misplaced. Given the original context, comp.lang.c++ seemed like the best choice, even though the remarks above don't involve C++ per se.) |
| Bonita Montero <Bonita.Montero@gmail.com>: Feb 22 02:31PM +0100 Is there a mandated order of addresses of string-literals inside a translation unit ? Or is there only the known requirement of order of initialization inside a translation unit of objects with a con- structor; because for that it wouldn't make a difference if the order of addresses would be different from the order of initiali- zation. |
| 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