- Simple Program from 2.3.2 of Stroustrup 3/e - 6 Updates
- Some classic (GoF) design patterns are no longer needed in C++ - 5 Updates
- "C++17 Is Now Official" - 11 Updates
- Semantics of comma operator - 3 Updates
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 15 05:25PM On 15/01/2018 14:34, Alf P. Steinbach wrote: > set_item_check( Static_id::set_enabled, not is_disabled_ ); > set_item_check( Static_id::set_disabled, is_disabled_ ); > } Modulo "m_" why do you choose the worst naming convention possible of mixed case AND underscores IN THE SAME SYMBOL? Egregious. /Flibble -- "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| Ian Collins <ian-news@hotmail.com>: Jan 16 07:55AM +1300 On 01/16/2018 03:34 AM, Alf P. Steinbach wrote: > using Static_id = menu::Static_cmd_id; > const auto set_item_check = [&]( const Static_id::Enum i, > const bool value ) Why did you const qualify the parameters? -- Ian |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 15 11:37PM +0100 On 1/15/2018 6:25 PM, Mr Flibble wrote: >> } > Modulo "m_" why do you choose the worst naming convention possible of > mixed case AND underscores IN THE SAME SYMBOL? Egregious. I think you mean to ask about the rationale of the naming convention. It is of course the goodest on Earth. ;-) The trailing underscore for member names is short and doesn't conflict with the various rules for reserved names. It's the convention used in Boost. Underscores as word separators are nice in Windows programming. It's easy to see that they're not Microsoft symbols. Also they're generally much more clear and readable, IMHO, than PascalCase. Leading uppercase for a type name makes it easy to identify types as such, and lets you have a type and a variable with same name in the admittedly very few cases where it's unnatural to invent other names. The only reason I can think of for not combining those desirable traits would be that it's currently somewhat unconventional. I guess that's where your "worst" and "egregious" come from, gut reactions to seeing something unfamiliar. But objectively it's a good combination. ;-) Cheers & hth., - Alf |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 15 10:43PM On 15/01/2018 22:37, Alf P. Steinbach wrote: > would be that it's currently somewhat unconventional. I guess that's > where your "worst" and "egregious" come from, gut reactions to seeing > something unfamiliar. But objectively it's a good combination. ;-) Speaking "objectively" that is simply your opinion. You are correct it is unconventional and it is unconventional for a reason: egregiousness. Now reply to Ian to explain your egregious const qualified function parameter clusterfuck. /Flibble -- "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 15 11:45PM +0100 On 1/15/2018 7:55 PM, Ian Collins wrote: >> const auto set_item_check = [&]( const Static_id::Enum i, >> const bool value ) > Why did you const qualify the parameters? The rationale for `const` on formal arguments in a function definition is the same as the rationale for `const` on local variables, and vice versa. Mainly that it, in the general case, constrains the possible effects of the code, so that the code is easier to grok and reason about. It's something that I do automatically unless there is a very good reason to not do it, for about the same reason that a car driver signals her intended direction at a cross-roads even where there are no other cars or people, and would need to decide very positively to not do it. Cheers!, - Alf |
| Ian Collins <ian-news@hotmail.com>: Jan 16 11:52AM +1300 On 01/16/2018 11:45 AM, Alf P. Steinbach wrote: > is the same as the rationale for `const` on local variables, and vice versa. > Mainly that it, in the general case, constrains the possible effects of > the code, so that the code is easier to grok and reason about. Um, you are probably in a small minority there. To my eyes they are just clutter. In our code base I remove spurious parameter qualifiers almost as zealously as I remove passing integral types by const reference! > reason to not do it, for about the same reason that a car driver signals > her intended direction at a cross-roads even where there are no other > cars or people, and would need to decide very positively to not do it. A better analogy would be using hazard lights to indicate driving straight... -- Ian. |
| legalize+jeeves@mail.xmission.com (Richard): Jan 15 08:24PM [Please do not mail me a copy of your followup] "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> spake the secret code >There will always be implementations of design patterns, in languages >and libraries and ordinary code. [...] e.g. sometimes Strategy pattern is just an if statement. -- "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> |
| legalize+jeeves@mail.xmission.com (Richard): Jan 15 08:25PM [Please do not mail me a copy of your followup] Jorgen Grahn <grahn+nntp@snipabacken.se> spake the secret code >Aren't design patterns generally seen as a historical mistake these >days? Just Singleton :) -- "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> |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 15 08:45PM On 15/01/2018 20:24, Richard wrote: >> There will always be implementations of design patterns, in languages >> and libraries and ordinary code. [...] > e.g. sometimes Strategy pattern is just an if statement. Nonsense. /Flibble -- "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| "Öö Tiib" <ootiib@hot.ee>: Jan 15 01:46PM -0800 On Monday, 15 January 2018 22:25:44 UTC+2, Richard wrote: > >Aren't design patterns generally seen as a historical mistake these > >days? > Just Singleton :) Every misuse is mistake. On one hand Singleton is simpler to misuse than for example Visitor or Memento. On the other hand misused Visitor or Memento are far more painful to live with than misused Singleton. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 15 10:35PM On 15/01/2018 21:46, Öö Tiib wrote: > Every misuse is mistake. On one hand Singleton is simpler to misuse > than for example Visitor or Memento. On the other hand misused Visitor > or Memento are far more painful to live with than misused Singleton. Actually a misused singleton can be extremely painful to rectify as it can result on everything erroneously depending on everything else (tight coupling). /Flibble -- "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| Thiago Adams <thiago.adams@gmail.com>: Jan 15 08:43AM -0800 > integration into build processes. > G-d willing, we'll add support for Wireshark to the CMW > in the future. I hope to explain were external generators doesn't work so well. Take C++ vector. You can create a template vector class. Then you can instantiate the vector<int> v and instantiate v.push_back. When you call v.push_back in your code the function push_back is instantiated. If you remove the line where you call push_back the function instantiation is removed. Everything is synchronized and The generated code depends on the code you write. Take an enum. You want to create a function to convert from enum value to text. enum E {A, B}; const char* ToString(E e) { switch (e) { case A: return "A"; case B: return "B"; } return ""; } If you have an external online generator you need to copy and paste your enum definition. If code generation as part of the language you don't need to do this process manually every time you change the enum. The second advantage with an "code generator" integrated with the language is that your code is portable and someone with the compiler can compile you code without download more tools and the language is know by programmers. (Don't need to learn each DSL language in the world). External code generators works if you don't need to change the "source" too much and don't need to synchronize too much and you must be happy with the generated code without changes. Some of these problems also happens with parser generators. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 15 05:28PM > Brian > Ebenezer Enterprises > https://github.com/Ebenezer-group/onwards What could be the possible motivation to back-port to earlier versions of product? What is the business case? Even more basically, what is the necessity? "Being easy to do" is not a good enough reason. Just use the latest version of the compiler if you want the latest version of the language. /Flibble -- "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| woodbrian77@gmail.com: Jan 15 09:31AM -0800 On Monday, January 15, 2018 at 10:43:43 AM UTC-6, Thiago Adams wrote: > } > If you have an external online generator you need > to copy and paste your enum definition. If the front-end of the on-line generator is web based, you probably have to copy/paste. I started off with a web based front-end, but switched to a command line interface so you don't have to copy/paste anything. Brian Ebenezer Enterprises http://webEbenezer.net |
| woodbrian77@gmail.com: Jan 15 10:16AM -0800 On Monday, January 15, 2018 at 11:28:36 AM UTC-6, Mr Flibble wrote: > necessity? "Being easy to do" is not a good enough reason. Just use the > latest version of the compiler if you want the latest version of the > language. I have the luxury of using new compilers in some of my work, but not everyone is as blessed. For a number of reasons that have been discussed previously in other threads, people are stuck with older compilers. C++ 2011 was both late and immature when it did arrive. Better late than never, but things were a mess. The back-porting is to finally get C++ 2011 right. Brian Ebenezer Enterprises http://webEbenezer.net |
| Ian Collins <ian-news@hotmail.com>: Jan 16 08:02AM +1300 > but not everyone is as blessed. For a number of reasons that > have been discussed previously in other threads, people are > stuck with older compilers. Quite. Back-porting to a compiler would change the compiler, so anyone stuck on an older version would remain stuck. The version with back ported bits would be a different compiler version requiring the same qualification as a new compiler. -- Ian. |
| woodbrian77@gmail.com: Jan 15 11:13AM -0800 On Monday, January 15, 2018 at 1:02:28 PM UTC-6, Ian Collins wrote: > stuck on an older version would remain stuck. The version with back > ported bits would be a different compiler version requiring the same > qualification as a new compiler. True, but 3 of the 4 items I listed are library only. The other one is a simplification of a C++ 2011 feature. So in these cases, I don't think what you are saying matters that much. Brian Ebenezer Enterprises - "I have a dream that my four little children will one day live in a nation where they will not be judged by the color of their skin, but by the content of their character." Martin Luther King, Jr. http://webEbenezer.net |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 15 08:22PM > True, but 3 of the 4 items I listed are library only. The other > one is a simplification of a C++ 2011 feature. So in these cases, > I don't think what you are saying matters that much. There are three options: 1) your compiler costs money in which case the company that makes it needs a business case to forgo profit; 2) your compiler is free in which case download the latest version; 3) you are genuinely stuck with an old compiler for technical reasons in which case you are genuinely stuck with an old compiler for technical reasons. /Flibble -- "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| scott@slp53.sl.home (Scott Lurndal): Jan 15 08:53PM >True, but 3 of the 4 items I listed are library only. The other >one is a simplification of a C++ 2011 feature. So in these cases, >I don't think what you are saying matters that much. Doesn't matter what you think. As Ian noted, any change in the compilation environment (headers, libraries, compilers, etc) requires significant validation prior to rolling out for production, which costs time and money. |
| "Öö Tiib" <ootiib@hot.ee>: Jan 15 01:19PM -0800 On Monday, 15 January 2018 22:53:54 UTC+2, Scott Lurndal wrote: > compilation environment (headers, libraries, compilers, etc) requires > significant validation prior to rolling out for production, which > costs time and money. That is all time and money of compiler vendors and compiler users. Brian does not consider that since it is not his time and money. He just wants only few new features but also wants those to compile on C++11 compiler. He needs miracle. |
| Vir Campestris <vir.campestris@invalid.invalid>: Jan 15 09:54PM On 15/01/2018 20:22, Mr Flibble wrote: > 3) you are genuinely stuck with an old compiler for technical reasons in > which case you are genuinely stuck with an old compiler for technical > reasons. There are 4 options - 4) Some of the code base won't build on the new compiler (IME this is usually because of bugs, and it's worth fixing them) ... OK, among the options are 5) Parts of the company are scared to change the compiler in case it destabilises things They don't have to be good reasons. Andy -- Nobody expects the Spanish Inquisition! |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 15 10:29PM On 15/01/2018 20:53, Scott Lurndal wrote: > compilation environment (headers, libraries, compilers, etc) requires > significant validation prior to rolling out for production, which > costs time and money. Also what you would end up with is a bastardized version of C++ that bears no relation to an official incarnation of C++ but I guess we kind of always have that situation anyway due to compiler vendors being slow on the uptake of new language features implementing some not all (hello Microsoft). /Flibble -- "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| David Brown <david.brown@hesbynett.no>: Jan 15 05:09PM +0100 On 15/01/18 16:08, Manfred wrote: > Bad practice is not the same as crazy, I think. Besides, you wrote > yourself that there are cases where code cannot be written to be easily > readable. Yes, I was a bit harsh. But there is a big difference between code that has to be hard because it is a complex task, and knowingly making code harder when there is a clear and obvious way to make it easier to follow. For most operator expressions, the precedence is easy to see and get right - but where it is not, you put in the extra parenthesis (or split up the expression - there is no need to put everything in one expression or one line). >> expression should be split up.) > I tend to agree with the baseline, although I think that expression > splitting serves more that readability only. Yes. Splitting it up can make it easier to follow. It can give you additional naming points to make the logic clearer. It can make types more explicit (that is quite relevant in my line of work, where types smaller than "int" are common and unsigned arithmetic is often used - you can make your integer promotions explicit and force conversion to unsigned types without needing casts). It can enforce the ordering of evaluations, give you lines for breakpoints, make it easier to add temporary "printf debugs", asserts, etc. I very rarely use the comma operator because it can easily be misinterpreted. /I/ know how it works, and can get the precedence levels right most of the time even without looking up a reference - but I certainly can't be sure that applies to everyone who might be reading my code. So in most cases where I might think about using the comma operator, or using the result of an assignment expression, I will consider splitting up the expression instead. My aim is that where possible, the code can be understood at a glance - it should be as easy as possible to interpret it correctly, and as hard as possible to interpret it incorrectly. Minimising the number of parenthesis or keeping everything in one complicated expression is /way/ down in my list of priorities. > This is different than a work environment, where "time is money"[1], so > you want to make life easy for yourself and your colleagues, and if a > couple of parentheses can help, you should definitely use them. It is not about "time is money" - it is about making it as easy as possible to be correct (in reading and writing code), and as hard as possible to be wrong. Saving money (with reduced test/debug/re-code cycles) is a bonus - writing quality code in the first place is the aim. > [1] In a school context, on the other hand, priority should be knowledge. Presumably at a school you are teaching people to be able to use the language in the real world. You thus must teach them to write code in a good way - as clearly as possible. You also, as a teacher, do not give your students sample code that is so messy and obfuscated that you can't understand it yourself without looking up the details! Of course, you also have to teach the students to understand worse code than you teach them to write - they will see all sorts of stuff in the real world. But that is a minor part in comparison to teaching them good practices. |
| "James R. Kuyper" <jameskuyper@verizon.net>: Jan 15 12:09PM -0500 On 01/14/2018 04:54 PM, Stefan Ram wrote: [Re: precendence levels in C] > Ok, now correcting, using notes: > ram@zedat.fu-berlin.de (Stefan Ram) writes: I forgot that this was comp.lang.c++, not comp.lang.c. I've corrected my message accordingly: To the extent that the rules of the C++ language can be described in terms of operator precedence (which is a considerable extent), the precedence levels correspond to the sub-sections 1-19 of section 8 (sub-section 20 doesn't quite fit into the precedence concept). 8.1: Primary expressions: "literal" this >> (x) id_expression [lambda_capture](parameter declaration){return result;} [x ... y] 8.2: Postfix expressions. >> x[...] >> x.... Your notation is confusing, because the member selection operator blends in with your ellipses. I assume you meant what I would describe using x.member >> x(...) > Here, a new level should have started by writing > an empty line. No, this is not a different level. >> x++ >> x++ > Was intended to read "x--". (int){x, y} (type_name_specifier){x, y} int {x, y} type_name_specifier {x, y} x.template id_expression x->template id_expression x.~type_name x->~type_name dynamic_cast<type_id>(x) static_cast<type_id>(x) reinterpret_cast<type_id>(x) const_cast<type_id>(x) typeid(x) typeid(type_id) 8.3: Unary operators >> !x >> ~x > forgot: &x, *x, sizeof x alignof(type_name) new type_id(x) delete x noexcept(x) 8.4: explicit type conversion (cast notation) > forgot: (cast)x 8.5: Pointer-to-member operators x.*y x->*y 8.6: Multiplicative operators >> x*y >> x/y > forgot: x%y 8.7: Additive operators >> x+y >> x-x 8.8: Bitwise shift operators >> x<<y >> x>>y 8.9: Relational operators > Oops, a major omission: Totally forgot > x<y, x>y, x<=y and x>=y here. 8.10: Equality operators > x==y x!=y 8.11: Bitwise AND operator >> x&y 8.13: Bitwise exclusive OR operator >> x|y 8.12: Bitwise inclusive OR operator >> x^y ??? > ^ is higher than |, I thought about that > possibility, but was not sure. 8.14: Logical AND operator >> x&&y 8.15: Logical OR operator >> x||y || has lower precedence than &&. 8.16: Conditional operator >> x?y:z (does not exactly fit) To be precise, the way in which it fails to fit is that any expression between the '?' and the ':' is evaluated in it's entirety, and used as the second operand of the operator, so in that regard, ?: has lower precedence than any other operator. However, with regard to its first operand, it behaves as if it were just lower than ||. With respect ot its third operand, it behaves exactly as if it had precedence just lower than that of assignment expressions. 8.17: Throwing an exception throw(x) 8.18: assignment operators >> x = y >> x += y and so on 8.19: Comma operator |
| Manfred <noname@invalid.add>: Jan 15 07:16PM +0100 On 1/15/2018 5:09 PM, David Brown wrote: > On 15/01/18 16:08, Manfred wrote: >> On 1/15/2018 1:13 AM, David Brown wrote: <snip> > good way - as clearly as possible. You also, as a teacher, do not give > your students sample code that is so messy and obfuscated that you can't > understand it yourself without looking up the details! Yes, the teacher should be familiar with what he is teaching. > than you teach them to write - they will see all sorts of stuff in the > real world. But that is a minor part in comparison to teaching them > good practices. My point about schooling stems from an observation about general schooling of our world: In the context of (human) language teaching (e.g. primary or middle school), be it English, German, French, Chinese, whatever, I would understand, even appreciate, that students be encouraged to use a language that is somewhat more formal than commonly used, i.e. make a wider use of the language rules, even those that are not commonly used, for the sake of getting acquainted with the rules themselves. On the other hand, when someone becomes a journalist, then it is perfectly understandable to stick to a plain and simple style of writing, to facilitate immediate comprehension by the public. I believe one consequence of having the school sticking to mimic "the real world" (and avoid going beyond what is of common use) is that it is nowadays so common to read incorrect grammar everywhere, from private email to published newspapers - which is a symptom of widespread ignorance. Back to the topic of teaching how to code (which I would not be able to do), yes "keeping things simple" is a major programming skill that /must/ be taught, nonetheless I would keep in mind the difference I tried to exemplify above between the school and the "real world": even if a good programmer produces code that is as simple and clear as possible, the student should be able to handle complex constructs, and in order to do that he must have used them - so better use them at school than at work. |
| 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