Saturday, April 11, 2020

Digest for comp.lang.c++@googlegroups.com - 25 updates in 4 topics

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: