- Help needed - 11 Updates
- overuse of auto is dangerous - 1 Update
- two's complement idea - 1 Update
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 04 04:16PM +0200 > And you're using a lot of uninized variables as function-parameters; > that's a lot of bugs. In some cases the variable is initialized in loop before and the compiler can't see if the loop is actually executed. So if the loop is actually exectuted at least only once nearly everything is fine but you just have to set the variable to an aribtrary value at initialization. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Apr 04 10:27AM -0400 On 4/4/20 12:58 AM, Ned Latham wrote: > James Kuyper wrote: >> Ned Latham wrote: ... > 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. What's with you? I only asked for a simple explanation for an obscure comment. OK, so you've made it clear that you're complaining about something you know little about. That's fine - I'd feared that you were describing some recent changes to the language that I hadn't noticed (Unfortunately, for me, "recent" could include changes dating as far back to C++2017). Throwing exceptions and declaring namespaces remains optional, and are not the default. Your function will throw exceptions only if it explicitly uses throw(), or if it calls a subroutine that uses throw() outside of a try-block - that's the same as it has always been. Everything in the C++ standard library that can be declared inside a namespace is so declared, and many routines in the standard library do throw exceptions. Both of those statements have been true since shortly after those features were added to the language. However, your own code doesn't have to throw exceptions, use namespaces, or use the C++ standard library. ... > I'd rather put that learning curve into designing and implementing > a well-thought-out language. Then I would recommend not bothering to monitor a newsgroup devoted to a language that you hate. ... >> Could you identify what you consider to be defective about C++'s >> post-increment semantic? > It doesn't work with non-native types. It works with any user-defined type that defines an operator overload for that operator, or can be implicitly converted to a type for which it's permitted. > Post-decrement too, of course. That's not "of course" - the fact that you explicitly specified "post-increment" implies that your complaint is specifically about that operator. Based upon the reason you've given, I'm surprised that you're not complaining equally strongly about all of the other arithmetic operators. You can't apply any of the following operators to a user-defined type: + - ! ^= &= <= >= [] * < |= && / > << || % += >> ^ -= >>= -- & *= <<= | /= == ->* ~ %= != Unless, of course, an applicable operator overload is defined or there's conversion operators or conversion constructors defined that will convert a value of that type to a different type for which those operators are permitted. Note: in that list, "&" refers to the binary operator - unary & can, of course, be applied to any object of any type. |
| Paavo Helde <eesnimi@osa.pri.ee>: Apr 04 05:39PM +0300 04.04.2020 15:25 Ned Latham kirjutas: >> 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::). Ignorance is bliss, they say. > *sigh* I dunno. It looked like a good language thirty years ago. Some > hangover shit from C, but overall one of the best. C++ has many problems, but for me it's still the best language around. It has never let me down, regardless of how low-level I need to go in the implementation or how high level I want to go in the interfaces and design. Most languages have built up high walls there, either in one (C) or both directions (Java, C#, etc). You are right in that the current C++ (and especially its idiomatic use) is quite different from the pre-standard C++ dialects used in the last century. If all your C++ knowlegde and experience becomes from year 1997, this just means that every opinion you express about current C++ is mostly just babbling. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Apr 04 10:44AM -0400 On 4/4/20 1:35 AM, Ned Latham wrote: > Ian Collins wrote: >> Ned Latham wrote: >>> James Kuyper wrote: ... > You use cout, you risk an exception. That hasn't changed - since shortly afer exceptions were first added to the language, if you call a function that can throw an exception, and don't catch the exception, your function will throw that exception. > How do they prevent them from occurring? try{ } catch{}. >>> 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. >> Says who? > I do. If the only reason it's compulsory is because you said it, and you don't like it being compulsory, then I recommend that you stop saying that it's compulsory. There's no one else whose said anything to make explicit use of namespaces compulsory. Strictly speaking, if you don't declare something inside an explicitly declared namespace, it is implicitly declared in a separate unnamed namespace, which is a separate namespace for each translation unit. So declaring something inside a namespace is technically unavoidable. However, the concept of an unnamed namespace has no practical effect on your code - being implicit, it never needs to be named. The concept only exists because it makes it easier to word various rules concerning namespaces. And again, that's a feature of the language that has existed since shortly after namespaces were first added to the language - it is not a change. >>> Post-decrement too, of course. >> How so? > I just told you. It doesn't work. Unless you declare an applicable operator overload, in which case it does work. Why would you want it to work on a user-defined type that doesn't have such an overload? Why, for instance, should the standard allow you to write myContainer++, and what in the world would you want it to do if you did allow such a construct? |
| David Brown <david.brown@hesbynett.no>: Apr 04 04:49PM +0200 On 04/04/2020 14:15, Ned Latham wrote: >> language did not have exception support. > I checked again. The nearest I can see is -mno-fp-exceptions. Different > versions, I suppose. Perhaps along with your pre-standard C++ from the early nineties, you are using a compiler of that age. Either that, or you don't know how options in gcc work. (If that's just lack of knowledge, it is easily solved - follow the link I gave you.) >> 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. Do you assume that you know all the uses other people might have for features in a language? You seem to be parading your ignorance and self-centred views as though they were something to be proud of. The C++ language, C++ programmers, and the programming world in general has moved on in the last 25 years. You can stay in the past if you want, but insulting and condemning everyone who has moved on is completely inappropriate. It is certainly the case that for most decisions and features there will be some people who like them and find them useful, some who don't use them but see no harm in them, and some who think they are a bad idea or find them a problem. No one is suggesting that you have to adopt all the new features of C++. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Apr 04 10:51AM -0400 On 4/4/20 3:22 AM, Ned Latham wrote: >> Ned Latham wrote: >>> Ian Collins wrote: >>>> Ned Latham wrote: ... >>> You use cout, you risk an exception. >> Do you? > You wanna tell me how you don't? try { } catch{}; >>> How do they prevent them from occurring? >> Compile with exceptions disabled. > How? Disabling exceptions renders an implementation non-conforming. How to do it is therefore outside the scope of the C++ standard, and is implementation-specific. If your preferred implementation doesn't provide such a method, your complaint is with the implementors, not with the C++ language. ... >>> I do. >> Ah, so it isn't "compulsory". Good to know. > What part of "it seems" did you fail to understand? The part where it represents anything other than a misconception on your part. >> Yeah right, very helpful. > Get a clue. Increment has only one action, and I didn't mention > pre-increment. That leaves only one possibility. Yes, but most of us have no trouble applying post-increment to user-defined types that have an appropriate operator overload defined, and see no reason to want to apply post-increment to a type that doesn't define such an overload. Therefore, the fact that you want to apply post-increment to a type where you can't apply post-increment is an anomaly that calls for an more detailed explanation. |
| David Brown <david.brown@hesbynett.no>: Apr 04 04:57PM +0200 On 04/04/2020 14:19, Bonita Montero wrote: >> feature - ... > It's not a "commonly used feature" since nearly the whole standard > -library throws exceptions. It is a commonly used feature, since many C++ programming standards, many C++ projects, and many companies do not use exceptions in their C++ code. A prime example is Google, whose coding standard disallows exceptions. Another is the small embedded systems programming world (roughly speaking, systems where the processor runs a single program rather than an OS supporting multiple programs) where disabling exceptions and RTTI is the norm. You will also find exceptions to be disabled in many high-performance coding tasks, such as games. Exceptions are definitely useful for many purposes, but equally definitely not ideal in all systems. It is not a surprise that various "error return" mechanisms such as "expected" and "optional" are on the uptake. The proposals for a more lightweight and deterministic exception mechanism may turn out to be a better compromise between different error-handling solutions. |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 04 06:58PM +0200 > loop is actually exectuted at least only once nearly everything > is fine but you just have to set the variable to an aribtrary > value at initialization. Sorry, what I told was nonsense. I checked it with the following code: unsigned f123(); unsigned f456( unsigned a, unsigned b ) { unsigned j; for( ; a != b; ++a ) j = f123(); return j; } The compiler can't say for sure if f123 is called. But it doesn't complain about that f123 might not get called. |
| Ian Collins <ian-news@hotmail.com>: Apr 05 07:35AM +1200 On 05/04/2020 02:33, Ned Latham wrote: >> double amount; >> operator double() const { return amount; } > What's this for? It's not used, below. It is. >> } > 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. No, it doesn't. The code compiles and behaves exactly as intended and your inability to comprehend it clearly demonstrates what I thought all along, you are clueless. -- Ian. |
| Ian Collins <ian-news@hotmail.com>: Apr 05 07:37AM +1200 On 05/04/2020 02:27, James Kuyper wrote: >> "transitioning" to it. Now, it seems, its use is compulsory. >> I will not tolerate that either. > What's with you? It's called trolling :) -- Ian. |
| Sam <sam@email-scan.com>: Apr 04 04:30PM -0400 Gerry Wolff writes: > * This project is part of a long-time research programme, and I would of > course give credit for help with programming in papers arising from the new > research. So, you're asking for assistance fixing old C++ code to the new C++ standard in exchange for …credit in a research paper? > jgw@cognitionresearch.org. Please say something briefly about your > experience with Visual C++, and the time you would have available to work on > what I've described. It seems like you have very high standards, for accepting free help. I'm sure it would be an honor of a lifetime for someone to, most likely, sink massive amounts of time in cleaning up old code base that, most likely, was written by someone without much formal C++ training, knowledge, and experience; in exchange for recognition in some research paper that few people will ever read. This is obviously a drive-by posting, and this is likely just pissing into the wind: but you'll have far more success circulating your request amognst graduate students in Comp Sci in your institution of higher learning. I can't fathom anyone else caring to give a whit. |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Apr 04 12:49PM -0700 >> compared to where the function is defined, even though you >> can't think of any good reason to do so? > There's no inconsistency between that possibility and what Keith said; That is a true statement. > people often do things without having a good reason for doing them. That also is a true statement. > He also only said that he couldn't think of any good reasons Not exactly correct, but we can let that slide. > - that > wording explicitly allows for the possibility of reasons he couldn't > think of. Not correct. It implicitly allows for such a possibility, but not explicitly. > In fact, his comment could even be interpreted as an > invitation to enlighten him about what such reasons might be. Yes it could. His comment also could be interpreted as hinting that he thinks there are no good reasons. > Can you so enlighten him? AFAIK he isn't seeking enlightenment, and I wouldn't presume to suppose otherwise. > If not, there was really no point in responding. Your purposes are not my purposes. |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Apr 04 12:37PM -0700 > that it is too general. That's the reason why more restricted > statements (break and continue) exist even though they could be > replaced by goto-s. goto is unstructured. return (and creturn) is structured. |
| 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