- "C++ proposal dismisses backward compatibility" - 16 Updates
- Help needed - 6 Updates
- Updated draft list - 1 Update
- Class declaration - 2 Updates
Lynn McGuire <lynnmcguire5@gmail.com>: Apr 06 12:41PM -0500 "C++ proposal dismisses backward compatibility" https://www.infoworld.com/article/3535795/c-plus-plus-proposal-dismisses-backward-compatibility.html "Proposal to the C++ standards committee would give up backward and binary compatibility for safety and simplicity" Lynn |
alelvb <alelvb@inwind.it>: Apr 06 09:32PM +0200 Il 06/04/20 20:35, Ned Latham ha scritto: > Safety and simpolicity are both good ideas, but if they *really* head > down that path, they might as well define it strongly and give it a > new name. C3? I'd propose C³ - C cubed ; ) cheers |
Melzzzzz <Melzzzzz@zzzzz.com>: Apr 06 07:41PM > Safety and simpolicity are both good ideas, but if they *really* head > down that path, they might as well define it strongly and give it a > new name. C3? Yes. C++ is used because of it's backwards compatibility. Changing code costs time and money... -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
alelvb <alelvb@inwind.it>: Apr 06 09:44PM +0200 Il 06/04/20 21:41, Melzzzzz ha scritto: >> new name. C3? > Yes. C++ is used because of it's backwards compatibility. Changing code > costs time and money... ...and the rewriting of many tools and libraries |
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 06 11:32PM +0200 On 06.04.2020 22:33, Jorgen Grahn wrote: > Most authors seem to be Google employees. I wonder how much of a > serious suggestion it is, and how much it's a provocation intended > to start a discussion on language goals. Have you considered an April Fool's joke, like Google's previous roman numerals proposal, or Bjarne's significant whitespace proposal? - Alf (who hasn't looked at that) |
Keith Thompson <Keith.S.Thompson+u@gmail.com>: Apr 06 02:40PM -0700 > Have you considered an April Fool's joke, like Google's previous roman > numerals proposal, or Bjarne's significant whitespace proposal? > - Alf (who hasn't looked at that) No, the paper was published on March 2. -- 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 */ |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Apr 06 05:16PM -0700 On 4/6/2020 12:32 PM, alelvb wrote: >> down that path, they might as well define it strongly and give it a >> new name. C3? > I'd propose C³ - C cubed ; ) :^D Nice. |
Marcel Mueller <news.5.maazl@spamgourmet.org>: Apr 07 05:58AM +0200 Am 06.04.20 um 21:44 schrieb alelvb: >> Yes. C++ is used because of it's backwards compatibility. Changing code >> costs time and money... > ...and the rewriting of many tools and libraries This will not happen (excluding some exceptions). No one ever pays for no business value. And no open source programmer spends time just for nothing. And every new platform which did not start with a reasonable large base of usable software is a stillbirth. Remember D (and several other languages), Win Phone, dozens of Raspberry Pi replacements, non x86 compatible CPUs. Successful incompatible platforms require a promoter who pays for years for the development of the software ecosystem. In contrast totally antiquated platforms like COBOL are still alive. Or remember SAP (ABAP). One of their success factors is the language compatibility. Code of the 90's still run on their platform with minimal changes. Marcel |
Cholo Lennon <chololennon@hotmail.com>: Apr 07 01:13AM -0300 On 4/6/20 2:41 PM, Lynn McGuire wrote: > https://www.infoworld.com/article/3535795/c-plus-plus-proposal-dismisses-backward-compatibility.html > "Proposal to the C++ standards committee would give up backward and > binary compatibility for safety and simplicity" I'd like to see a new C++ without backward compatibility, but I know that this is a key feature, but at the same time a huge pain in the neck. And we already have several examples about breaking the backward compatibility like Python2 vs Python3. I don't want to be in the middle of that kind of scenario. The referenced paper is very interesting BTW. -- Cholo Lennon Bs.As. ARG |
David Brown <david.brown@hesbynett.no>: Apr 07 08:35AM +0200 On 06/04/2020 21:32, alelvb wrote: >> new name. C3? > I'd propose C³ - C cubed ; ) > cheers Surely C+=2 would be the natural choice? |
Melzzzzz <Melzzzzz@zzzzz.com>: Apr 06 06:13PM > https://www.infoworld.com/article/3535795/c-plus-plus-proposal-dismisses-backward-compatibility.html > "Proposal to the C++ standards committee would give up backward and > binary compatibility for safety and simplicity" Bad idea. C++ will be then like languages who break old code every now and then. Not for professionals... -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
Jorgen Grahn <grahn+nntp@snipabacken.se>: Apr 06 08:33PM On Mon, 2020-04-06, Lynn McGuire wrote: > https://www.infoworld.com/article/3535795/c-plus-plus-proposal-dismisses-backward-compatibility.html > "Proposal to the C++ standards committee would give up backward and > binary compatibility for safety and simplicity" Most authors seem to be Google employees. I wonder how much of a serious suggestion it is, and how much it's a provocation intended to start a discussion on language goals. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Apr 06 05:16PM -0700 On 4/6/2020 10:41 AM, Lynn McGuire wrote: > "Proposal to the C++ standards committee would give up backward and > binary compatibility for safety and simplicity" > Lynn Well... shi%. Bust out the legacy code that worked fine, then figure out how its ruined. |
Marcel Mueller <news.5.maazl@spamgourmet.org>: Apr 07 06:09AM +0200 Am 06.04.20 um 20:13 schrieb Melzzzzz: >> binary compatibility for safety and simplicity" > Bad idea. C++ will be then like languages who break old code every now > and then. Not for professionals... Full ack. A fork of the language will be the consequence. Marcel |
Marcel Mueller <news.5.maazl@spamgourmet.org>: Apr 07 06:07AM +0200 Am 06.04.20 um 19:41 schrieb Lynn McGuire: > https://www.infoworld.com/article/3535795/c-plus-plus-proposal-dismisses-backward-compatibility.html > "Proposal to the C++ standards committee would give up backward and > binary compatibility for safety and simplicity" This would be another new language which (almost) no one uses unless some other one pays him for years to do so. It's like reinvention of the wheel. The value of a programming company (or a community project) is the code base. Whatever breaks the compatibility decreases this value. There are a few business cases where compatibility is not an issue or even not wanted. But this applies only to very large companies and near-monopoly. They can exclude competitors this way. Marcel |
David Brown <david.brown@hesbynett.no>: Apr 07 10:28AM +0200 On 06/04/2020 19:41, Lynn McGuire wrote: > "Proposal to the C++ standards committee would give up backward and > binary compatibility for safety and simplicity" > Lynn (Disclaimer - I haven't read the link in detail.) Given that new languages come and go all the time, a new C++ would not be unreasonable - /if/ it is a fork with a new name and does not hinder existing C++. The best idea would be if it were a subset of C++. C++ has a great deal of historical baggage that can't be dropped because of backward compatibility, but which is not necessary. For example, you could re-do a fair amount of the fundamental types and give a simpler and safer language. Drop the dog's breakfast of character types and integer types, and retain "std::byte", "char8_t", "char32_t", "intXX_t" and "uintXX_t". Make it an error to combine signed and unsigned integers in most expressions without an explicit conversion. Requite 8-bit std::byte. Raw pointers could be banned unless a "#pragma unsafe" was in effect. Code written to this new subset would still compile correctly on standard C++ compilers. I'm sure this would be possible - but far from easy. |
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. |
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 |
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 . |
James Kuyper <jameskuyper@alumni.caltech.edu>: Apr 04 10:27PM -0400 On 4/4/20 9:33 AM, Ned Latham wrote: >>>> Ned Latham wrote: >>>>> Jorgen Grahn wrote: >>>>>> Ned Latham wrote: ... >> e.g. about lifetime of temporaries. > I always regard those as lasting until their return. I have no idea what "their return" is supposed to mean. The general rule is that temporaries last until the end of the full-expression that contains them. There's three main exceptions, the most important of which occurs when a temporary is bound to a reference. >> 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. Well, he did say "if properly defined". To reproduce behavior comparable to that for the built-in types, you need merely declare the operator overload as returning a value of the same type, and define the operator overload to create a copy of the current object before incrementing it, and to return that copy. You won't get the behavior you've described above if you follow those rules. >> double amount; >> operator double() const { return amount; } > What's this for? It's not used, below. That implements a conversion from Non-native to double, and it is used below. >> } >> Non_native operator++( int ) > double is non-native? No, but Non_native contains a double, and is implicitly convertible to a double. I'm curious - how did you misinterpret the above code so as to lead to that question? >> { >> Non_native o = {3.14}; >> cout << "Originally " << o++ << "." << endl; You said that operator double() was not used. It might help you understand this code to realize that it's equivalent to the following: cout << "Originally " << o.operator++(1).operator double() << "." << endl; If you don't understand why those two statements are equivalent, please explain what part you do understand, and we can fill in the rest. >> cout << "After: " << o << "." << endl; Similarly, that line is equivalent to: cout << "After: " << o.operator double() << "." << 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. No, the rules of C++ cause operator double() to be called in each of the relevant cases, and there are operators already defined for << working on doubles. There's no need to declare or define operator=(); C++ rules cause it to be implicitly declared and implicitly defined, and the implicitly defined operator=() does precise what is needed. That's not a coincidence - those rule were created specifically to save developers the trouble of defining operator=() explicitly. You only need to explicitly declare or define it in circumstance the implicit declaration/definition doesn't do what you want it to do. |
James Kuyper <jameskuyper@alumni.caltech.edu>: Apr 05 04:59PM -0400 On 4/5/20 12:31 PM, Ned Latham wrote: >> As a response to that comment, "Says who" should be interpreted as a >> short form for the question "Who says that it's use is compulsory?". > Wrong. OK - so you've made it clear that you're misunderstanding ordinary English sentences. However, that's not a particular useful response, because it lacks an explanation. As a result, I have no idea which misunderstanding of that sentence is the one you believe to be correct. This is long overdue - Plonk. |
Juha Nieminen <nospam@thanks.invalid>: Apr 07 06:33AM > Contrary to what you suggest, I've had a brilliant response from someone who has done a very thorough review and updating of my SP71 C++ program. I could not have asked for more. So you got someone to do your work for you, for free. Congratulations. I wish I could have someone do my work for me, for free. |
Ben Bacarisse <ben.usenet@bsb.me.uk>: Apr 03 05:34PM +0100 > I have updated my draft list. Most recent entries at the top. Useful. Thanks. -- Ben. |
Keith Thompson <Keith.S.Thompson+u@gmail.com>: Apr 10 06:04PM -0700 >> Of course even that is miles more modern than Borland C for DOS. > Yes, gcc 4 has fairly/nearly complete C++11 support, and doesn't > really cripple your designs. (Except notably std::regex is broken.) Is that a compiler issue or a library issue? If you're running an old version of RedHat, you're probably stuck with old versions of both gcc and the library (GNU libstdc++) unless you rebuild both from source, so it might not make much practical difference which package is at fault. -- 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 */ |
Jorgen Grahn <grahn+nntp@snipabacken.se>: Apr 11 05:32AM On Sat, 2020-04-11, Keith Thompson wrote: >> Yes, gcc 4 has fairly/nearly complete C++11 support, and doesn't >> really cripple your designs. (Except notably std::regex is broken.) > Is that a compiler issue or a library issue? Library: https://gcc.gnu.org/onlinedocs/gcc-4.8.5/libstdc++/manual/manual/status.html#status.iso.2011 > old versions of both gcc and the library (GNU libstdc++) unless you > rebuild both from source so it might not make much practical difference > which package is at fault. True. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
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