| Stuart Redmann <DerTopper@web.de>: Oct 01 02:29PM +0200 Hello newsgroup, Sorry for being off-topic. I just wondered why open source tools like gcc or clang don't use error codes like for example MS Visual C does. If I want to refer to a particular compilation error under VC, I can simply use its code. For example, one of the recent threads in this group deals with C5038. If I mention this number here everyone can just type this in his/her favorite search engine and knows what I'm talking about. With gcc/clang this is much more cumbersome: I have to extract the part of the error message that looks like it would sensible results and type this into my search engine (simply copy-pasting might also copy names of my classes or variables, which might give Mr. SearchEngine sensitive information about what I'm doing. And no, I don't want to use DuckDuckGo, Brian). Does anyone else think that MS's error codes are a good thing? Regards, Stuart |
| David Brown <david.brown@hesbynett.no>: Oct 01 03:04PM +0200 On 01/10/2020 14:29, Stuart Redmann wrote: > variables, which might give Mr. SearchEngine sensitive information about > what I'm doing. And no, I don't want to use DuckDuckGo, Brian). Does anyone > else think that MS's error codes are a good thing? There are pros and cons. You've covered some of the pros of having codes. gcc gives warning and error messages in text format. If these are connected to optional flags, rather than always active (like syntax errors in the code), the warning or error message gives the relevant flag. You can refer to or search for that just as easily as for any code from MSVC. But a key difference is that the flag has a definite meaning - it's easy to guess what "-Wunused-function" refers to, but impossible to guess what "C5038" might mean. (For some warning flags, it is not always clear from the name - but it's usually quite close to obvious.) This also applies when specifying flags in a Makefile or other build system. I've had very little use of MSVC, but have worked with other compilers that deal entirely in such meaningless codes - Makefiles and project setups are incomprehensible and unmaintainable unless they are filled with comments, and you have to keep looking up everything. The single real benefit, as I see it, of error codes is that they can be easier to parse by automated tools (like an editor or IDE). gcc has that covered too now, with options to provide messages in a software-friendly format rather than human friendly (to the extent that compilers and error messages are ever "friendly") messages. No compiler I have ever used is ideal (IMHO) with regard to either flags or messages, but on this one point, for my taste, gcc wins hands down against MSVC. |
| "Öö Tiib" <ootiib@hot.ee>: Oct 01 08:19AM -0700 On Thursday, 1 October 2020 15:30:17 UTC+3, Stuart Redmann wrote: > Does anyone > else think that MS's error codes are a good thing? Yes, I think that: * having error/warning code for each diagnostic is better for searching its further elaboration in documentation or online forums and better for whatever automatic tools. * showing error or warning code in front of any further explaining message (instead of after) is better for automatic tools and TL;DR people. * the error/warning code being some numerical or base64 garbage (instead of terse textual) is worse for human operator and worse for whomever who configures or scripts tools. |
| Brian Wood <woodbrian77@gmail.com>: Sep 30 09:22PM -0700 On Sunday, September 27, 2020 at 9:57:50 AM UTC-5, Öö Tiib wrote: > Who cares? There are technology companies with billion dollar turnover > whose IT does not just let to put such system into their network. > Case closed. I'm not seeking to persuade large companies. I'm focused on individuals and small companies. Large companies have spent how many billions developing O3 optimizations? In the talk "Performance Matters" https://www.reddit.com/r/cpp/comments/j2nxi1/plenary_performance_matters_emery_berger_cppcon/ Emery Berger claims that the difference between O2 and O3 is noise -- not statistically relevant. If you've followed this newsgroup for any length of time, you will recall that I've been an O3 skeptic. I can back that up with my Github repo. Mr. Berger also has the temerity to mention Mount Sinai, tablets and G-d in the talk. > tutorials etc. are all there). > 3) Answers or links for questions that one does not want to search from docs. > * what platforms are supported? FreeBSD, Linux, Mac, Windows. It can be extended to others fairly easily. > * where is forum? > * where is issue tracker? > * where is q/a site? I'm not sure which one to start with of the last three. > * how to contribute? https://webEbenezer.net/about.html > * what is usage license? https://github.com/Ebenezer-group/onwards/blob/master/LICENSE BSD License Copyright (c) 2016-2020, Brian Wood All rights reserved. https://webEbenezer.net Redistribution and use in source and binary forms, with or without modification, are permitted. Brian |
| "Öö Tiib" <ootiib@hot.ee>: Oct 01 02:52AM -0700 On Thursday, 1 October 2020 07:23:15 UTC+3, Brian Wood wrote: > focused on individuals and small companies. > Large companies have spent how many billions developing > O3 optimizations? That misses what I meant. I meant that if even large and powerful technology companies try to keep their technology stack narrow and focused to reduce costs then your idea that successful small companies or individuals do not care about it is wildly misplaced. > > * what platforms are supported? > FreeBSD, Linux, Mac, Windows. It can be extended to others > fairly easily. I mean't you should try to honestly explain in your README.md why it is so what Alf asked and otherwise try to be close enough to clarity of your competitors. > > * where is issue tracker? > > * where is q/a site? > I'm not sure which one to start with of the last three. I can't imagine projects without issue tracker. The q/a site and forum can be merged and you can perhaps use something like discord or reddit for those ... main problem is that it does take constant, possibly irritating, efforts. And put the other things also to your README.md, no one will search those from comp.lang.c++ |
| "daniel...@gmail.com" <danielaparker@gmail.com>: Oct 01 07:42AM -0700 > Can you give me some suggestions on how to > improve this: > https://github.com/Ebenezer-group/onwards Your README has to answer the question: what is this thing and why would anybody want to use it? "[Provides] support for messaging and serialization" isn't enough. Lots of C++ libraries with active communities and large user bases have that. Many support standardized, schema-less data formats such as JSON, CBOR and MessagePack, and thus have interoperability. Some are quite good at non-intrusive serialization. What does your library offer that is compelling enough to win converts? Daniel |
| olcott <NoOne@NoWhere.com>: Sep 30 06:27PM -0500 On 9/30/2020 2:58 PM, David Brown wrote: > For simple types with trivial construction and assignment, such as those > in examples in this thread, initialisation and assignment will likely > give the same generated code. That is what I thought. -- Copyright 2020 Pete Olcott |
| Ian Collins <ian-news@hotmail.com>: Oct 01 01:04PM +1300 On 30/09/2020 10:38, olcott wrote: > >>> declared in the class definition > I proved that the constructor can force the initialization order to be > different than the order they were declared in the class definition. Only in the limited case of non-const and non-reference members. -- Ian. |
| olcott <NoOne@NoWhere.com>: Sep 30 07:20PM -0500 On 9/30/2020 7:04 PM, Ian Collins wrote: >> I proved that the constructor can force the initialization order to be >> different than the order they were declared in the class definition. > Only in the limited case of non-const and non-reference members. I think that it has been agreed that members can be constructed in any arbitrary order overriding the order that they were declared. -- Copyright 2020 Pete Olcott |
| Ian Collins <ian-news@hotmail.com>: Oct 01 01:48PM +1300 On 01/10/2020 13:20, olcott wrote: >> Only in the limited case of non-const and non-reference members. > I think that it has been agreed that members can be constructed in any > arbitrary order overriding the order that they were declared. No, it hasn't. Consider struct X { int a; const int b; X( int _a, int _b ) : b {_b}, a {_a} {} }; $ clang++ -Wall x.cc x.cc:6:25: warning: field 'b' will be initialized after field 'a' [-Wreorder-ctor] X( int _a, int _b ) : b {_b}, a {_a} {} ^ 1 warning generated. 'b' must be initialised in an initialiser list. -- Ian. |
| olcott <NoOne@NoWhere.com>: Sep 30 08:54PM -0500 On 9/30/2020 7:48 PM, Ian Collins wrote: > int b; > X( int _a, int _b ){ b = _b; a = _a; }; > }; const have to be initialized they can't be constructed. -- Copyright 2020 Pete Olcott |
| Ian Collins <ian-news@hotmail.com>: Oct 01 02:57PM +1300 On 01/10/2020 14:54, olcott wrote: > > X( int _a, int _b ){ b = _b; a = _a; }; > > }; > const have to be initialized they can't be constructed. I think you are confusing initialisation, construction and assignment... -- Ian. |
| olcott <NoOne@NoWhere.com>: Sep 30 09:50PM -0500 On 9/30/2020 8:57 PM, Ian Collins wrote: >> > }; >> const have to be initialized they can't be constructed. > I think you are confusing initialisation, construction and assignment... Yes. -- Copyright 2020 Pete Olcott |
| David Brown <david.brown@hesbynett.no>: Oct 01 08:28AM +0200 On 30/09/2020 23:01, James Kuyper wrote: > is pretty much the simplest rule that could be defined, and puts the > order fully under the control of the class definition. I doubt that > there's any more complicated reasons than that for this decision. Yes, that sounds reasonable. Someone else in this thread mentioned destructor order, and of course that is another reason why initialisation order must be consistent (in the semantics of the language, ignoring the "as if" rule). This really should have been obvious to me if I had thought before writing! > Ralf: keep in mind that Dave's suggestion of printing merely serves as > an example. Any other shared resource would serve equally well as a > reason why the order would matter. Indeed. |
| Stuart Redmann <DerTopper@web.de>: Oct 01 09:37AM +0200 > initialisation order must be consistent (in the semantics of the > language, ignoring the "as if" rule). This really should have been > obvious to me if I had thought before writing! Don't worry, I've been following this thread because I knew there was a simple and compelling reason, why the initialization order had to be tied to the declaration order, but I just couldn't remember it. Hopefully it will not slip my mind so easily again :-) Of course, the idea that the order of the initializations in the initialization list could determine the initialization order is also attractive. If a class has only one constructor, it could be done without any problems (some rules would be necessary with regard to members that are initialized at the point of their declaration). However, if a class provided multiple constructors, and the initialization list order of these constructors differed, the class would have to remember the initialization order somehow (simple enum should suffice), so that it can employ the proper destruction order in the destructor. This would mean, that the class' size had to increase. Come to think about it, the scheme with the flexible initialization order is not so bad as it gives us more flexibility. And if we don't use this flexibility, it does not add any penalties (more memory, more instructions) to the current way of doing things, this neatly embracing the design principle of C++: „Don't pay for something that you don't use." Regards, Stuart |
| David Brown <david.brown@hesbynett.no>: Oct 01 09:48AM +0200 On 01/10/2020 09:37, Stuart Redmann wrote: > order somehow (simple enum should suffice), so that it can employ the > proper destruction order in the destructor. This would mean, that the > class' size had to increase. Yes, and that would quickly be a mess. Order by declaration in the class is likely to be the simplest and most practical solution. |
| Ralf Goertz <me@myprovider.invalid>: Oct 01 10:00AM +0200 Am Wed, 30 Sep 2020 17:23:13 +0200 > The initialization order is important. And the standard tells you > that in order to control the initialization order you have to arrange > the /declaration/ order accordingly. I don't want to sound obstreperous (I just looked up that word, never heard it before but I hope it means what the dictionary suggests). I'm perfectly aware that the initialization order is important. What I don't see is why it has to follow declaration order. Why not not care at all about declaration order and initialize in the order of the explicit initialization? I don't see how this can hurt. If there are no explicit initializations in the class there is no harm in doing the implicit initialization in declaration order. But when explicit initialization is used do it in that order. If that leads to the access of uninitialized memory the compiler should warn about that and not about the wrong order. > Paavo has already mentioned the destructor requirement of reverse > destruction order (which is both a consistency requirement and a > performance enabler). I also don't see how the destructor order comes into play. Just have the compiler destroy the objects in the reverse order it initialized them regardless of where the order came from. > work. Since there can be multiple constructors, the natural choice is > the order of declaration, which is guaranteed to be univocal across > all translation units. But every code that initializes or destroys an object knows the complete class and can take care of the correct order. A translation unit can't destroy anything it hasn't constructed right?. I do see that for consistence sake it is *nice* to have the same declaration and initialization order. But I am not sure it is necessary. |
| Ralf Goertz <me@myprovider.invalid>: Oct 01 10:04AM +0200 Am Wed, 30 Sep 2020 19:53:04 +0300 > complicated. Also, this would imply that different constructors may > construct the members in different order, making their dependencies > and the life of the programmer much more complex. Maybe my understanding is too limited here. But I thought that in order to destroy an object in a particular translation unit this unit must be able to see the whole class. So the initialization order should be easily deductable. |
| Ralf Goertz <me@myprovider.invalid>: Oct 01 10:11AM +0200 Am Thu, 1 Oct 2020 09:37:38 +0200 > would have to remember the initialization order somehow (simple enum > should suffice), so that it can employ the proper destruction order in > the destructor. This would mean, that the class' size had to increase. I admit that differing initialization orders in different constructors would be a problem. But that would then be the right place to have the compiler spit out an order warning. > more instructions) to the current way of doing things, this neatly > embracing the design principle of C++: „Don't pay for something that > you don't use." Exactly, :-) |
| Paavo Helde <myfirstname@osa.pri.ee>: Oct 01 11:39AM +0300 01.10.2020 10:37 Stuart Redmann kirjutas: > class' size had to increase. > Come to think about it, the scheme with the flexible initialization order > is not so bad as it gives us more flexibility. This is a kind of flexibility similar to replacing for loops with gotos, or worse. A complicated and error-prone solution to a non-existing problem. > flexibility, it does not add any penalties (more memory, more instructions) > to the current way of doing things, this neatly embracing the design > principle of C++: „Don't pay for something that you don't use." Increasing the class size means a penalty, and in general this cannot be avoided because the class size must be determined by the class definition in the header file, whereas constructor definitions might only appear in separate translation units or libraries and might not be accessible at this point. Moreover, changing the cpp file containing a class constructor may now change the class size, requiring recompilation of all code including the class header file, even though the header file itself is not changed! |
| Paavo Helde <myfirstname@osa.pri.ee>: Oct 01 11:47AM +0300 01.10.2020 11:00 Ralf Goertz kirjutas: > But every code that initializes or destroys an object knows the complete > class and can take care of the correct order. A translation unit can't > destroy anything it hasn't constructed right?. Of course it can. I guess you are forgetting about dynamically allocated objects. Even if all class destructor and all constructors (including compiler-generated ones) happen to be defined in the same translation unit, the destructor might still not know by which constructor the object was created, and the correct order would need to be encoded somewhere, taking extra space and extra time for processing. |
| "Fred. Zwarts" <F.Zwarts@KVI.nl>: Oct 01 11:53AM +0200 Op 01.okt..2020 om 10:11 schreef Ralf Goertz: > I admit that differing initialization orders in different constructors > would be a problem. But that would then be the right place to have the > compiler spit out an order warning. That could be almost impossible for a compiler, as the two constructors might be in different compilation units. So, the compiler does not necessarily see the different orders in one compilation run. -- Paradoxes in the relation between Creator and creature. <http://www.wirholt.nl/English>. |
| "Fred. Zwarts" <F.Zwarts@KVI.nl>: Oct 01 12:00PM +0200 Op 01.okt..2020 om 10:04 schreef Ralf Goertz: > to destroy an object in a particular translation unit this unit must be > able to see the whole class. So the initialization order should be > easily deductable. No, that's why there are virtual destructors. A pointer to a base class in a translation unit could point to a derived class that is not known in that translation unit. When deleting the pointer the translation unit just calls the virtual destructor of the derived class, without knowing anything of the derived class. So, the information of the destruction order must be present somewhere inside the class. -- Paradoxes in the relation between Creator and creature. <http://www.wirholt.nl/English>. |
| Manfred <noname@add.invalid>: Oct 01 03:44PM +0200 On 10/1/2020 10:00 AM, Ralf Goertz wrote: >> that in order to control the initialization order you have to arrange >> the /declaration/ order accordingly. > I don't want to sound obstreperous That's a nice one :) (I just looked up that word, never > used do it in that order. If that leads to the access of uninitialized > memory the compiler should warn about that and not about the wrong > order. See below. > I also don't see how the destructor order comes into play. Just have the > compiler destroy the objects in the reverse order it initialized them > regardless of where the order came from. That would be a runtime operation that may be impossible to define at compile time. >> all translation units. > But every code that initializes or destroys an object knows the complete > class and can take care of the correct order. That's the point: it knows the complete class /as declared/, because the class definition is its declaration, not the (initialization list of the) constructor. A translation unit can't > destroy anything it hasn't constructed right?. I do see that for > consistence sake it is *nice* to have the same declaration and > initialization order. But I am not sure it is necessary. It is necessary because there can be multiple translation units that define multiple constructors, plus a possibly additional translation unit that defines the destructor. All of them must follow a unique definition, that is the class /declaration/. |
| "The Doctor" <doctor@doctor.nl2k.ab.ca>: Oct 01 12:01PM XanaNews Statistic for comp.lang.c++. 10/1/2020 6:01:37 AM From article 418053 (9/1/2020 1:17:24 AM) to article 418640 (9/30/2020 10:22:58 PM) Number of threads ................... 45 Number of articles .................. 595 Average articles per thread ......... 13.22 Number of unanswered posts .......... 13 Number of posts from XanaNews users .. 1 Top Threads Ranking Articles Subject ------- -------- ---------------------------------- 1 121 Why should a "c" programmer learn c++ ? (V2) 2 86 Microsoft dropped the ball... 3 75 Question on padding and alignment of `struct` and its members 4 68 Why should a "c" programmer learn c++ ? 5 32 max without ifs 6 26 Re: Simply defining Gödel Incompleteness and Tarski Undefinability away V52 (HP refutation) 7 26 Re: Are there any asm-instructions to support OOP 8 19 Re: Why halt deciders can't be "interesting" programs. (H is bad?) 9 12 Re: Bit Swizzling 10 12 Re: Transforming "C" into a Turing equivalent language 001 [Providing unlimited memory access to C] 11 11 Re: Clarification of PO's UTM architecture and his H and H_Hat 12 10 problem with std::string::c_str() 13 10 neoGFX Design Studio 14 7 Re: [OT] Re: Saint Paul, Minnesota user group 15 7 Cause error if integral parameter too large 16 7 "C++20 approved, C++23 meetings and schedule update" by Herb Sutter 17 7 Hex ASCII to raw binary on Unix-like 18 6 Mapping "C" to a Turing equivalent abstract model of computation 19 6 cannot find C++ regex tester 20 4 [Video] Dependency Injection with Boost.DI (Utah C++ Programmers) 21 4 Re: Are bitfields useful? 22 3 Re: Refraining from embracing 23 3 Re: Ridiculously high standards? 24 3 set_intersection_sorted 25 3 Re: "C++ Creator Bjarne Stroustrup Weighs in on Distributed Systems, Type Safety and Rust" 26 2 Available C++ Libraries FAQ 27 2 Transforming "C" into a Turing equivalent language 007 [Turing equivalent x86 computations] 28 2 Change 29 2 Change 30 2 Webserver PHP running C++ program 31 2 Turn 32 2 Transforming "C" into a Turing equivalent language 001 [x86 based UTM] Top Posters Ranking Articles Name Most Used Newsreader ------- -------- -------------------------- -------------------- 1 110 olcott Mozilla 2 45 David Brown Mozilla 3 42 Juha Nieminen tin 4 27 Öö Tiib G2 5 25 Bonita Montero Mozilla 6 22 Richard Damon Mozilla 7 20 Mr Flibble Mozilla 8 16 Keith Thompson Gnus 9 16 James Kuyper Mozilla 10 15 Chris M. Thomasson Mozilla 11 15 Chris Vine Sylpheed 12 15 Jorgen Grahn slrn 13 15 Paavo Helde Mozilla 14 14 Tim Rentsch Gnus 15 14 Ben Bacarisse 16 12 Brian Wood G2 17 12 Ian Collins Mozilla 18 10 Anton Shepelev Sylpheed 19 9 RM Mozilla 20 8 Christian Hanné Mozilla 21 8 boltar@nuttyella.co.uk 22 7 Rick C. Hodgin Mozilla 23 7 Melzzzzz slrn 24 7 Scott Lurndal xrn 25 6 Pankaj Jangid Gnus 26 5 André G. Isaak Mozilla 27 5 Bart Mozilla 28 5 Mike Terry Mozilla 29 5 Jeff Barnett Mozilla 30 4 Bo Persson Mozilla 31 4 Leo Mozilla 32 3 Cholo Lennon Mozilla 33 3 Manfred Mozilla 34 3 Real Troll 35 3 daniel...@gmail.com G2 36 3 Andrey Tarasevich Mozilla 37 3 wyniijj@gmail.com G2 38 3 Vir Campestris Mozilla 39 3 Ralf Goertz Claws Mail 40 3 rick.c.hodgin@gmail.com G2 41 3 Alf P. Steinbach Mozilla 42 3 Frederick Gotham G2 43 3 Richard trn 44 2 james...@alumni.caltech.ed G2 45 2 ijw wij G2 46 2 Marcel Mueller Mozilla 47 2 Kaz Kylheku slrn 48 2 Sam http: 49 1 Siri Cruise MT-NewsWatcher 50 1 Tim Woodall slrn 51 1 Ed Vance VSoup 52 1 jacobnavia Mozilla 53 1 Nikki Locke Nikkis auto poster 54 1 Lew Pitcher Pan 55 1 antispam@math.uni.wroc.pl tin 56 1 Eli the Bearded Vectrex rn 57 1 Lynn McGuire Mozilla 58 1 red floyd Mozilla 59 1 alrote Mozilla 60 1 Stuart Redmann NewsTap 61 1 Richard Harnden Mozilla 62 1 Udo Steinbach Mozilla 63 1 Joe Pfeiffer Gnus 64 1 The Doctor XanaNews 65 1 Ike Naar slrn Top Newsreaders Ranking Articles Newsreader Users ------- -------- -------------------------------------------- ----- 1 353 Mozilla 30 2 57 G2 9 3 43 tin 2 4 37 Gnus 4 5 26 slrn 5 6 25 Sylpheed 2 7 25 <unknown> 3 8 7 xrn 1 9 3 trn 1 10 3 Claws Mail 1 11 2 http: 1 12 1 Nikkis auto poster 1 13 1 VSoup 1 14 1 MT-NewsWatcher 1 15 1 Pan 1 16 1 XanaNews 1 17 1 NewsTap 1 18 1 Vectrex rn 1 -- This email has been checked for viruses by AVG. https://www.avg.com |
| 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