- Help needed - 25 Updates
| Bo Persson <bo@bo-persson.se>: Apr 04 02:10AM +0200 On 2020-04-03 at 22:05, Mr Flibble wrote: >> errors. There is the idiotic for-scoping that was wrong in VC6. In VC >> 6, if you write > VC6 is NOT a C++ compiler, it is VC6 compiler. True, in a way. Note that VC6 was published slightly before the C++98 standard was completed. In 1997, when VC6 was implemented, the draft for the standard said that the loop variable *should* be visible in the outer scope. Then that rule was changed, and the standard was published. Bo Persson |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Apr 04 01:14AM +0100 > ... In C++ every string literal has the type "const char *"; In fact they have array type. "abc" has type "array of 4 const char". Of course, in most contexts array-valued expressions "decay" to pointer values. -- Ben. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Apr 04 12:15AM -0400 On 4/3/20 5:58 PM, Ned Latham wrote: >> decades ago (C++98) and a well-supported one today (C++11)? > Exception throwing: once an option, now the default. > "namespace": once an option, now a requirement. Could you identify the specific changes in the text of the standard that you're referring to, and when they happened? I'm not sure what those descriptions mean - every interpretation I've been able to come up with is something that, as far as I know, either has never been true, or has always been true - either way, there wasn't a change. However, I'm not yet fully up-to-date on anything more recent than C++98. I'm fairly up-to-date on C++2003, and understand many of the more recently added features well enough to make use of them. > I suppose I should confess that the bugs in C(++) are also part of my > problem with C++. They are the defective string definition in C, and > the defective post-increment semenatic of C++. Could you identify what you consider to be defective about C++'s post-increment semantic? |
| Ned Latham <nedlatham@woden.valhalla.oz>: Apr 03 11:58PM -0500 James Kuyper wrote: > > "namespace": once an option, now a requirement. > Could you identify the specific changes in the text of the standard that > you're referring to, and when they happened? No. I don't geek around with committee standards. The only C++ standard that I know is Stroustrup's: "Programming in C++", vol 3, 1997. Exception throwing was optional back then, which suits me fine, because one of my projects is a library, and that is no place for exceptions (frankly, I think they encourage sloppy programming, and I eschew them at all times, not just in libraries). At some point, which I haven't reached yet, it became the default. When I reach that point, I'll be dropping back to the previous compiler. Namespace wasn't on the curriculum when I started learning C++. I don't know when it was introduced, but in his book (vol 3) Stroustrup seems to imply that it's a new thing. He discusses, for example, "transitioning" to it. Now, it seems, its use is compulsory. I will not tolerate that either. > yet fully up-to-date on anything more recent than C++98. I'm fairly > up-to-date on C++2003, and understand many of the more recently added > features well enough to make use of them. I'd rather put that learning curve into designing and implementing a well-thought-out language. > > the defective post-increment semenatic of C++. > Could you identify what you consider to be defective about C++'s > post-increment semantic? It doesn't work with non-native types. Post-decrement too, of course. |
| Ian Collins <ian-news@hotmail.com>: Apr 04 06:06PM +1300 On 04/04/2020 17:58, Ned Latham wrote: > at all times, not just in libraries). At some point, which I haven't > reached yet, it became the default. When I reach that point, I'll be > dropping back to the previous compiler. Default, where? May contemporary projects (and Google's coding standards) don't permit exceptions. > I don't know when it was introduced, but in his book (vol 3) Stroustrup > seems to imply that it's a new thing. He discusses, for example, > "transitioning" to it. Namespaces where introduced in the origin 1998 C++ standard, the one described in Stroustrup's third edition. > Now, it seems, its use is compulsory. Says who? >> post-increment semantic? > It doesn't work with non-native types. > Post-decrement too, of course. How so? -- Ian. |
| Ned Latham <nedlatham@woden.valhalla.oz>: Apr 04 12:35AM -0500 Ian Collins wrote: > > dropping back to the previous compiler. > Default, where? May contemporary projects (and Google's coding > standards) don't permit exceptions. You use cout, you risk an exception. How do they prevent them from occurring? > described in Stroustrup's third edition. > > Now, it seems, its use is compulsory. > Says who? I do. > > It doesn't work with non-native types. > > Post-decrement too, of course. > How so? I just told you. It doesn't work. |
| Paavo Helde <myfirstname@osa.pri.ee>: Apr 04 09:02AM +0300 On 4.04.2020 0:58, Ned Latham wrote: >> decades ago (C++98) and a well-supported one today (C++11)? > Exception throwing: once an option, now the default. > "namespace": once an option, now a requirement. Exception throwing and namespaces were both in the first 1998 C++ standard. The problem with MSVC++ used to be that it purposefully chose to not follow the C++ standard in some places, but this has been mostly fixed in recent versions. What I find seriously objectionable is that the new C++ standards are actually *removing* things from the standard like std::auto_ptr and throw(), causing maintenance issues for old legacy codebases. |
| Ned Latham <nedlatham@woden.valhalla.oz>: Apr 04 01:20AM -0500 Paavo Helde wrote: > > "namespace": once an option, now a requirement. > Exception throwing and namespaces were both in the first 1998 C++ > standard. As options. > What I find seriously objectionable is that the new C++ standards are > actually *removing* things from the standard like std::auto_ptr and > throw(), causing maintenance issues for old legacy codebases. I don't use std: or throw(). They're both crocks, IMO. Maintenance issues are nothing new with C++. |
| Ian Collins <ian-news@hotmail.com>: Apr 04 07:43PM +1300 On 04/04/2020 19:20, Ned Latham wrote: >> Exception throwing and namespaces were both in the first 1998 C++ >> standard. > As options. No different from now. >> actually *removing* things from the standard like std::auto_ptr and >> throw(), causing maintenance issues for old legacy codebases. > I don't use std: or throw(). They're both crocks, IMO. So you are bitching about stuff that's been a standard part of the language for almost 23 years? That ship has sailed. -- Ian. |
| Ian Collins <ian-news@hotmail.com>: Apr 04 07:54PM +1300 On 04/04/2020 18:35, Ned Latham wrote: >> Default, where? May contemporary projects (and Google's coding >> standards) don't permit exceptions. > You use cout, you risk an exception. Do you? > How do they prevent them from occurring? Compile with exceptions disabled. >>> Now, it seems, its use is compulsory. >> Says who? > I do. Ah, so it isn't "compulsory". Good to know. >>> Post-decrement too, of course. >> How so? > I just told you. It doesn't work. Yeah right, very helpful. -- Ian. |
| Ned Latham <nedlatham@woden.valhalla.oz>: Apr 04 02:10AM -0500 Ian Collins wrote: > > > standard. > > As options. > No different from now. Crap. > > > throw(), causing maintenance issues for old legacy codebases. > > I don't use std: or throw(). They're both crocks, IMO. > So you are bitching Try reading with somne attention and commenting with some civility, you fuck. > about stuff that's been a standard part of the > language for almost 23 years? That ship has sailed. You don't get it. According to Paavo, they've been removed. By avoiding them, I've avoided the inconsistencies and the maintenance issues that their temporary presence caused. But then, you'd have to be a programmer to get it. |
| Ned Latham <nedlatham@woden.valhalla.oz>: Apr 04 02:22AM -0500 Ian Collins wrote: > Ned Latham wrote: > > Ian Collins wrote: > > > Ned Latham wrote: ----snip---- > > > standards) don't permit exceptions. > > You use cout, you risk an exception. > Do you? You wanna tell me how you don't? > > How do they prevent them from occurring? > Compile with exceptions disabled. How? ----snip---- > > > Says who? > > I do. > Ah, so it isn't "compulsory". Good to know. What part of "it seems" did you fail to understand? > > > How so? > > I just told you. It doesn't work. > Yeah right, very helpful. Get a clue. Increment has only one action, and I didn't mention pre-increment. That leaves only one possibility. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Apr 04 08:19AM On Fri, 2020-04-03, Christian Gollwitzer wrote: >> I just tried to compile your SP62-program. There are a lot assignments >> of string-literals to non-const string-pointers. In C++ every string >> -literal has the type "const char *"; I don't know if this has ever ... > I also tried to compile the SP71 program. There were only 7 real errors. ... Useful advise from Bonita and Christian! (Unlike a lot of other stuff in this thread.) /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Bo Persson <bo@bo-persson.se>: Apr 04 10:33AM +0200 On 2020-04-04 at 09:22, Ned Latham wrote: >>> You use cout, you risk an exception. >> Do you? > You wanna tell me how you don't? cout will only throw those exceptions you have explicitly enabled by calling cout.exceptions(exception_mask). So just don't. https://en.cppreference.com/w/cpp/io/basic_ios/exceptions Bo Persson |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Apr 04 01:58AM -0700 Ned Latham <nedlatham@woden.valhalla.oz> writes: [...] > Try reading with somne attention and commenting with some civility, > you fuck. [...] I request that everyone stop feeding this troll. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */ |
| Ned Latham <nedlatham@woden.valhalla.oz>: Apr 04 04:55AM -0500 Bo Persson wrote: > > You wanna tell me how you don't? > cout will only throw those exceptions you have explicitly enabled by > calling cout.exceptions(exception_mask). So just don't. I don't. But that's because I don't use *any* C++ libraries. > https://en.cppreference.com/w/cpp/io/basic_ios/exceptions Really? An incomplete section? It shows how to set an exception mask. There's nothing there about *disabling* exceptions. There's nothing there to say that they're disbled without explicit enablement. Similar with with the gcc man page. Plenty of options for exception types, nothing about disabling them. |
| Ned Latham <nedlatham@woden.valhalla.oz>: Apr 04 05:04AM -0500 Keith Thompson wrote: > > Try reading with some attention and commenting with some civility, > > you fuck. > I request that everyone stop feeding this troll. I request that someone give the whatever that calls itself Keith Thompson a dictionary and some coaching in civil discourse. |
| David Brown <david.brown@hesbynett.no>: Apr 04 01:02PM +0200 On 04/04/2020 11:55, Ned Latham wrote: > disbled without explicit enablement. > Similar with with the gcc man page. Plenty of options for exception > types, nothing about disabling them. <https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-fexceptions> Use "-fno-exceptions", and gcc will compile your C++ code as though the language did not have exception support. It is a commonly used feature - exceptions are good for some kinds of programming, less good for other kinds. |
| Paavo Helde <myfirstname@osa.pri.ee>: Apr 04 02:37PM +0300 On 4.04.2020 10:10, Ned Latham wrote: > You don't get it. According to Paavo, they've been removed. By avoiding > them, I've avoided the inconsistencies and the maintenance issues that > their temporary presence caused. I guess you probably confused throw() with exceptions. Both exceptions and namespaces (incl. std::) are very much in C++, won't go anywhere, are very useful, and I use them every day. What is removed is the no-throw specification 'throw()'. https://en.cppreference.com/w/cpp/language/except_spec : Syntax throw( ) (1) (deprecated in C++11)(removed in C++20) throw(typeid, typeid, ...) (2) (deprecated in C++11)(removed in C++17) |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 04 01:51PM +0200 On 04.04.2020 06:58, Ned Latham wrote: >> you're referring to, and when they happened? > No. I don't geek around with committee standards. The only C++ standard > that I know is Stroustrup's: "Programming in C++", vol 3, 1997. At that time, close up to the first standardization in 1998, the /de facto/ standard was the Annotated Reference Manual, the "ARM", by Bjarne Stroustrup and Margaret Ellis, IIRC. > Exception throwing was optional back then The standard exception hierarchy wasn't finished until close up to standardization, I believe about the time of that book, anyway after 1995. As I recall Microsoft's Visual C++ didn't implement the new hierarchy until some years after the standardization, I believe in Visual Studio.NET in 2003 or so. > seems to imply that it's a new thing. He discusses, for example, > "transitioning" to it. Now, it seems, its use is compulsory. > I will not tolerate that either. 1990's tools and techniques are fine, just fine, just not as convenient as modern approach. Stick with what you know. However, you'll have to adjust some details because compilers now generally conform to the ISO standard and not the ARM, e.g. about lifetime of temporaries. >> post-increment semantic? > It doesn't work with non-native types. > Post-decrement too, of course. You just have to defined custom operators where you want custom operators and then, if properly defined, they work fine. The post- operators take a dummy `int` argument, just to distinguish them. Here's an example: #include <iostream> using namespace std; // Do this to get roughly pre-standard behavior. struct Non_native { double amount; operator double() const { return amount; } void advance() { amount += 0.01; } Non_native operator++( int ) { Non_native result = *this; advance(); return result; } }; int main() { Non_native o = {3.14}; cout << "Originally " << o++ << "." << endl; cout << "After: " << o << "." << endl; } - Alf |
| Ned Latham <nedlatham@woden.valhalla.oz>: Apr 04 07:15AM -0500 David Brown wrote: > Ned Latham wrote: > > Bo Persson wrote: ----snip---- > <https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-fexceptions> > Use "-fno-exceptions", and gcc will compile your C++ code as though the > language did not have exception support. I checked again. The nearest I can see is -mno-fp-exceptions. Different versions, I suppose. > It is a commonly used feature > - exceptions are good for some kinds of programming, less good for other > kinds. Frankly, I can't see *any* use for it. It's nowhere near as context- sensitive as making the object report the error to the caller. But thanks for the info anyway. Indeed, thanx to all who contributed to this subthread. |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 04 02:19PM +0200 > Use "-fno-exceptions", and gcc will compile your C++ code as though the > language did not have exception support. It is a commonly used feature > - ... It's not a "commonly used feature" since nearly the whole standard -library throws exceptions. |
| Ned Latham <nedlatham@woden.valhalla.oz>: Apr 04 07:25AM -0500 Paavo Helde wrote: > On 4.04.2020 10:10, Ned Latham wrote: > > Ian Collins wrote: ----snip---- > > them, I've avoided the inconsistencies and the maintenance issues that > > their temporary presence caused. > I guess you probably confused throw() with exceptions. Could be. None of that stuff appeals to me, so I don't exactly go out of my way to learn its ins and outs. > Both exceptions > and namespaces (incl. std::) are very much in C++, won't go anywhere, > are very useful, and I use them every day. We're polar opposites then. I avoid them every day (including std::). > Syntax > throw( ) (1) (deprecated in C++11)(removed in C++20) > throw(typeid, typeid, ...) (2) (deprecated in C++11)(removed in C++17) *sigh* I dunno. It looked like a good language thirty years ago. Some hangover shit from C, but overall one of the best. |
| Ned Latham <nedlatham@woden.valhalla.oz>: Apr 04 08:33AM -0500 Alf P. Steinbach wrote: > At that time, close up to the first standardization in 1998, the /de > facto/ standard was the Annotated Reference Manual, the "ARM", by Bjarne > Stroustrup and Margaret Ellis, IIRC. Sounds familiar, though I don't have it. > As I recall Microsoft's Visual C++ didn't implement the new hierarchy > until some years after the standardization, I believe in Visual > Studio.NET in 2003 or so. 'Sfunny. I've been toying with the notion of developing a language that gives the programmer complete control of all elements of code generation, and one of the thoughts was that it might be a good idea to put a minimal version it out there and get help enhancing it. C++ shows pretty clearly that it's a bad idea. (Well, if it's done by committee.) ----snip---- > 1990's tools and techniques are fine, just fine, just not as convenient > as modern approach. Stick with what you know. That's one option. Another is a stable language, with context-sensitive error control. > However, you'll have to > adjust some details because compilers now generally conform to the ISO > standard and not the ARM, I will not be doing that. Next time I hit a version that wants me to alter my code, I'll dump it. Either downgrade or switch. > e.g. about lifetime of temporaries. I always regard those as lasting until their return. With the declarations # include <mclib.h> // The library I referred to earlier. and StringC one("I'm "), two("outta here."); the command (one + two).Write(stderr); puts "I'm outta here." on the error stream. And it (the temporary) really is. ----snip---- > > Post-decrement too, of course. > You just have to defined custom operators where you want custom > operators and then, if properly defined, they work fine. Nope. With non-native types passed to functions they pass the incremented value to the function. > The post- operators take a dummy `int` argument, just to distinguish them. I know. I spent weeks hacking the post- operators in an index class designed to provide random access to a list class. Trying to hack correct working into them. Managed it, but the hacks were ugly and inefficient and prevented the compiler from picking up errors. So LixtC, the indexor to ListC, has preincrements, but not post. > Here's an example: > #include <iostream> > using namespace std; // Do this to get roughly pre-standard behavior. Not me. Namespace is beyond the pale. > { > double amount; > operator double() const { return amount; } What's this for? It's not used, below. > amount += 0.01; > } > Non_native operator++( int ) double is non-native? > cout << "Originally " << o++ << "." << endl; > cout << "After: " << o << "." << endl; > } I'm not even going to try it, Alf, And I bet you haven't done so. That code requires overload operators = and << for the struct. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 04 02:50PM +0100 On 04/04/2020 12:51, Alf P. Steinbach wrote: [snipped] > using namespace std; // Do this to get roughly pre-standard behavior. No, just no. /Flibble -- "Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne 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." |
| 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