- Remember the Vasa! - 4 Updates
- "Why does most C/C++ developer prefers char *c instead of char* c? Pin" - 13 Updates
| Jorgen Grahn <grahn+nntp@snipabacken.se>: May 30 11:19AM On Tue, 2018-05-29, Jouko Koski wrote: > Bjarne Stroustrup himself is expressing some concerns about the C++ > language development: > http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0.pdf Good. People (hopefully) listen to Stroustrup, and I'm happy to see that he hasn't join the ADD school of language design. (I wasn't aware the committee had gotten that feature-happy though; that's a bit worrying.) /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Thiago Adams <thiago.adams@gmail.com>: May 30 06:42AM -0700 On Tuesday, May 29, 2018 at 7:47:18 AM UTC-3, Jouko Koski wrote: > are stated at least now. > -- > Jouko Some C++ programmers were waiting someone else to say that C++ is becoming too complex, and now they will be more comfortable to repeat that. "Modern C++" become a bad adjective in my option. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: May 30 02:53PM On Wed, 2018-05-30, Thiago Adams wrote: > Some C++ programmers were waiting someone else to say that > C++ is becoming too complex, and now they will be > more comfortable to repeat that. In my case, I respect Stroustrup for his good taste in language design, and haven't followed the ISO work in detail ... Doesn't mean I will join the small Usenet choir of whiners anytime soon. > "Modern C++" become a bad adjective in my option. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Christiano <christiano@engineer.com>: May 30 12:49PM -0300 On 05/30/2018 10:42 AM, Thiago Adams wrote: Thiago, the C++11 has move semantics which is fundamental and has improvements in the memory model (parallel programming), adds things that were already language idoms (unique_ptr), etc, etc, etc. You have a historic of pushing changes in C and C++ that are just what the Stroustrup criticizes. The fact is: 1- You push Absurd stupid ideas like "C array should be passed by value", promote radical changes all the time like crazy Without any fear in a mailing list (other) 2- At same time You criticize Just that you do !!!! Is like a person who offers drugs to someone while saying "You see? This person needs to get into my religion!!!" What is my conclusion? My conclusion is obvious: You have your Language Project which you Insistently spam in a other C++ mailing list, abusing the fact that you're a moderator. You play in the both sides (1 and 2) because at the end you want to promote your "language". Your objective is destroy C and C++ and promote your "language". As the Scott said: "That horse left the stable after C++11." But you have a very long historic looking for problems in C++98, C++11, C89, C11, etc and promoting radical breaking-code changes. You're just trying (ONE MORE TIME) to get another opportunity to promote your personal project and fuck all C and C++ tradition. But you're not the only one. When a proposal is accepted, the person proposing it gains prestige, prominence, media, etc. So it is obvious that there will be various people in the world promoting things that will destroy the language for personal gain. That's why I'm against this committee thing. In my opinion C ++ should be completely in the hand of Stroustrup. So it would be safe from malicious idiots with low moral standards. Or there should be a model like Parliamentary Monarchy which the king can intervene when he realizes that there is a bad intention going on. |
| "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: May 29 04:40PM -0700 On 5/29/2018 4:12 PM, Lynn McGuire wrote: > "Why does most C/C++ developer prefers char *c instead of char* c?" > https://www.codeproject.com/Lounge.aspx?msg=5523356#xx5523356xx > I prefer "char * c". For me _personally_, I prefer the star to be closer to its type. char const* const g = "Hello"; g is a const pointer, to a const char when read right to left. |
| legalize+jeeves@mail.xmission.com (Richard): May 29 11:48PM [Please do not mail me a copy of your followup] Lynn McGuire <lynnmcguire5@gmail.com> spake the secret code >"Why does most C/C++ developer prefers char *c instead of char* c?" > https://www.codeproject.com/Lounge.aspx?msg=5523356#xx5523356xx Without reading the link first, my answer is.... Because that's the way it was shown to me in K&R "C Programming Language", 1st ed. Where I work, they like 'char* c'. They pay me to make code for them, so I write it the way they want. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: May 29 04:49PM -0700 On 5/29/2018 4:48 PM, Richard wrote: > Language", 1st ed. > Where I work, they like 'char* c'. They pay me to make code for them, > so I write it the way they want. No problem with that! :^D |
| Barry Schwarz <schwarzb@dqel.com>: May 29 08:10PM -0700 On Tue, 29 May 2018 18:12:39 -0500, Lynn McGuire >"Why does most C/C++ developer prefers char *c instead of char* c?" > https://www.codeproject.com/Lounge.aspx?msg=5523356#xx5523356xx In my case because char* c, d; is visually misleading. d has type char, not char*. Using char *c, d; makes it clear, to me. -- Remove del for email |
| James Kuyper <jameskuyper@alumni.caltech.edu>: May 29 11:35PM -0400 On 05/29/2018 07:12 PM, Lynn McGuire wrote: > "Why does most C/C++ developer prefers char *c instead of char* c?" > https://www.codeproject.com/Lounge.aspx?msg=5523356#xx5523356xx > I prefer "char * c". For me, it's because it reflects the C grammar. I don't mean that it's required by the grammar. I mean that the grammar specifies that a declaration consists of a series of declaration specifiers followed by a list of init-declarators (6.7p1). In this declaration, the declaration specifiers consist entirely of the type specifier "char", while *c is the sole pointer declarator. Putting a space between the declaration specifiers and the init-declarators (a space NOT required by the grammar) helps remind me of that distinction. Let me give a bigger example, where I use a newline for the same purpose. In the declaration static int const _Alignas(double) array[32]={[1]=1, [2]=1, [4]=1, [8]=1, [16]=1}, * restrict pointer=array; The first line of that declaration contains all of the declaration specifiers. The second line contains the first init-declarator, and the third line contains the second init-declarator. All of the specifiers apply to both init-declarators, whereas nothing specified for the first init-declarator carries over to the second init-declarator, which is why it's important, in general, to keep the distinction between specifiers and declarators clear. However, if you never declare more than one identifier in a given declaration, you don't need to worry about that distinction. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: May 30 07:27AM +0200 On 30.05.2018 05:10, Barry Schwarz wrote: > is visually misleading. d has type char, not char*. Using > char *c, d; > makes it clear, to me. template< class T > using Type_ = T; Type_<char*> a, b; or template< class T > using Ptr_ = T*; Ptr_<char> a, b; Going down to the fundamental type builders, as in the last example, supports using prefix `const` everywhere. Almost like a sane programming language. Cheers!, - Alf |
| David Brown <david.brown@hesbynett.no>: May 30 08:58AM +0200 On 30/05/18 05:10, Barry Schwarz wrote: > is visually misleading. d has type char, not char*. Using > char *c, d; > makes it clear, to me. To me, they are /both/ visually misleading (though the second one is a little less bad), and I much prefer to write: char * c; char * d; Since I don't usually define a variable until I have an initial value, my identifiers are mostly more descriptive, and there may well be a comment, I very rarely see any reason to squeeze more than one identifier in the same declaration. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: May 30 08:51AM On Tue, 2018-05-29, Lynn McGuire wrote: > "Why does most C/C++ developer prefers char *c instead of char* c?" > https://www.codeproject.com/Lounge.aspx?msg=5523356#xx5523356xx > I prefer "char * c". The question is flawed; C programmers and C++ programmers have different conventions. You see more people saying 'char* c' in C++ (although it's not a universal difference). /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| bart4858@gmail.com: May 30 02:38AM -0700 [Attempting to post to C++ group only] On Wednesday, 30 May 2018 00:12:57 UTC+1, Lynn McGuire wrote: > "Why does most C/C++ developer prefers char *c instead of char* c?" > https://www.codeproject.com/Lounge.aspx?msg=5523356#xx5523356xx > I prefer "char * c". It's C type syntax, which has different characteristics depending on whether you're specifying a single nameless type, or declaring a list of N typed names. So you have to make the best of bad job. When declaring only a type (as in cast, or a nameless parameter), I would write "char*". If declaring only a list of names but N=1, these days I might write "char* c" taking advantage that in this case, I can keep the type specifier in one group (but that doesn't work when declaring one array as in "char c[]" as the type is split around the name). If declaring several such names, then I would probably write "char *c, *d" as otherwise "char* c, d" looks confusing: it resembles a saner language where you write "<typespec> c,d" with the same type applied to each name. I would very rarely mix types in a declaration, so I wouldn't write "char *c, d" and intend that only one is a pointer. And finally, if generating C code by software, I seem to remember using "char *" in each case, where the "*" looks rather lonely. But there, I only ever declare one name at a time so it probably doesn't matter. -- bart |
| Juha Nieminen <nospam@thanks.invalid>: May 30 09:41AM > "Why does most C/C++ developer prefers char *c instead of char* c?" > https://www.codeproject.com/Lounge.aspx?msg=5523356#xx5523356xx > I prefer "char * c". C++ inherits a lot of bad decisions from C, and I think that the rather convoluted syntax for pointers is one of them. Pointers, and their syntax, is one of the hardest things for a beginner programmer to learn, regardless of whether we are talking about C or C++. (Heck, it took me years to fully remember all the intricacies, even though I regularly coded in C and C++ as a hobby.) It's easy to think that the asterisk is tied to the type, even though it's not. Thus it's easy to get confused by declarations like: char* a, b; Of course if you have learned to always attach the asterisk to the type name, it's a habit that's hard to get rid of, even if you wanted to. Thus you often resort to inconsistent compromises, such as writing: char* a; char *b, *c; // Would look weird as "char* b, *c;" I know because I do that often, even though I try to avoid it. Of course even if you try to learn to attach the asterisk to the name, you then get dilemmas like: std::vector<char*> v; Now the asterisk looks like part of the type name, almost by necessity. I suppose you could use some slightly weird spacing like: std::vector<char *>v; but that's even more awful. Attaching the asterisk to the name actually makes a lot more sense when we are talking about things like function and array pointers, ie: int (*funcPtr)(int); int (*tablePtr)[12]; Here it would be weird to try to attach the asterisk, somehow, to the type name. Especially since the type name isn't a pointer (the "type name" in this case is int, not int*.) Incidentally, in Objective-C method declarations have the type of a parameter specified in parentheses, and a very common convention is to attach the asterisk to the variable name regardless. In other words, rather than write a method as: - (void) methodName: (int*) intPtr; it's often written by convention (eg. by Apple) as: - (void) methodName: (int *)intPtr; |
| bart4858@gmail.com: May 30 03:20AM -0700 On Wednesday, 30 May 2018 10:41:22 UTC+1, Juha Nieminen wrote: > It's easy to think that the asterisk is tied to the type, > even though it's not. Thus it's easy to get confused by > declarations like: char* a, b; I think it would be best to always think of the asterisk (it's harder with [] for arrays) as part of the type. This would work well for parameters (only one type per name), and casts (only one type with no name). For other name declarations, you can use a convention of only declaring one name per type. Or for several names all of the same type, it's possible to wrap the type in a typedef. Alternatively, using this gcc extension, you can do this: typeof(char*) p,q,r; Each of p, q and r has type char*. This extension also allows you to make an array specifier part of the type: typeof(char[10]) a,b,c; It even works for functions: typeof(int(int,int)) F {} although people might expect a mode traditional declaration here. Functions are usually declared one at a time. -- bart |
| Ian Collins <ian-news@hotmail.com>: May 30 10:36PM +1200 On 30/05/18 18:58, David Brown wrote: > To me, they are /both/ visually misleading (though the second one is a > little less bad), and I much prefer to write: > char * c; That's a multiplication ! :) -- Ian. |
| scott@slp53.sl.home (Scott Lurndal): May 30 01:35PM >or > template< class T > using Ptr_ = T*; > Ptr_<char> a, b; Good grief. What a waste of bytes. char *p char* p #define ASTERISK * char ASTERISK p who cares? |
| 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