"The C++ committee has taken off its ball and chain"

[Lynn McGuire]

"The C++ committee has taken off its ball and chain"

http://shape-of-code.coding-guidelines.com/2018/04/14/the-c-committee-has-taken-off-its-ball-and-chain/

“The Committee should be willing to consider the design / quality of
proposals even if they may cause a change in behavior or failure to
compile for existing code.”

Interesting only if C++ can generate faster code.

Hat tip to:

https://www.codeproject.com/script/Mailouts/View.aspx?mlid=13562&_z=1988477

Lynn

[Tim Rentsch]

Lynn McGuire <lynnmc...@gmail.com> writes:

> "The C++ committee has taken off its ball and chain"
>
> http://shape-of-code.coding-guidelines.com/2018/04/14/
> the-c-committee-has-taken-off-its-ball-and-chain/
>

> "The Committee should be willing to consider the design / quality of
> proposals even if they may cause a change in behavior or failure to
> compile for existing code."

The only thing I find suprising is that it has taken them so
long to say this out loud.

Thank you for posting the link.

[Jorgen Grahn]

On Thu, 2018-04-19, Lynn McGuire wrote:
> "The C++ committee has taken off its ball and chain"
>
> http://shape-of-code.coding-guidelines.com/2018/04/14/the-c-committee-has-taken-off-its-ball-and-chain/
>
> “The Committee should be willing to consider the design / quality of
> proposals even if they may cause a change in behavior or failure to
> compile for existing code.”

There's not a lot more detail in the article, though; mostly
historical background, and hints about breaking more C compatibility.
Any more thoughts about what this would mean in practice?

> Interesting only if C++ can generate faster code.

Why? Fast code is important, but it's not the only characteristic of
a language.

Personally I like conservative languages, like C++. "Exciting new
features" don't excite me -- or I'd be cargo-culting the
JVM-language-of-the-week instead.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Tim Rentsch]

Jorgen Grahn <grahn...@snipabacken.se> writes:

> On Thu, 2018-04-19, Lynn McGuire wrote:
>
>> "The Committee should be willing to consider the design / quality of
>> proposals even if they may cause a change in behavior or failure to
>> compile for existing code."
>

> Any more thoughts about what this would mean in practice?

I'd like to think it should be taken at face value: The
committee should be willing to /consider/ such proposals,
ie, and not just reject them out of hand. The bar for
/accepting/ said proposals could, and ideally would, be
quite a bit higher, but it would be good to at least look
at them.

[Paavo Helde]

On 19.04.2018 12:57, Tim Rentsch wrote:
> Jorgen Grahn <grahn...@snipabacken.se> writes:
>
>> On Thu, 2018-04-19, Lynn McGuire wrote:
>>
>>> "The Committee should be willing to consider the design / quality of
>>> proposals even if they may cause a change in behavior or failure to
>>> compile for existing code."
>>
>> Any more thoughts about what this would mean in practice?
>
> I'd like to think it should be taken at face value: The
> committee should be willing to /consider/ such proposals,

They have done this before, this is nothing new. "auto" and ">>" are the
first examples of considered *and* accepted changes which pop to mind.

[Tim Rentsch]

Like I said, now they're being open about it.

[Rick C. Hodgin]

On 4/18/2018 8:58 PM, Lynn McGuire wrote:
> "The C++ committee has taken off its ball and chain"
>
> http://shape-of-code.coding-guidelines.com/2018/04/14/the-c-committee-has-taken-off-its-ball-and-chain/
>
> “The Committee should be willing to consider the design / quality of
> proposals even if they may cause a change in behavior or failure to
> compile for existing code.”
>
> Interesting only if C++ can generate faster code.

A very interesting development.

--
Rick C. Hodgin

[Manfred]

On 4/19/2018 11:03 AM, Jorgen Grahn wrote:
> On Thu, 2018-04-19, Lynn McGuire wrote:
>> "The C++ committee has taken off its ball and chain"
>>
>> http://shape-of-code.coding-guidelines.com/2018/04/14/the-c-committee-has-taken-off-its-ball-and-chain/
>>
>> “The Committee should be willing to consider the design / quality of
>> proposals even if they may cause a change in behavior or failure to
>> compile for existing code.”
>

<snip>

> Personally I like conservative languages, like C++. "Exciting new
> features" don't excite me -- or I'd be cargo-culting the
> JVM-language-of-the-week instead.

I believe the same, and not only as personal preference.
Backwards compatibility is a very valuable property.

This is obvious from the perspective of software producers, expecially
the ones that are involved in long-living projects.

But it is also valuable for the language itself: it keeps it usable by
high-end projects, which usually have a long life, so that it motivates
highly skilled subjects (people and organizations) to put effort in
maintaining and improving the language.

From this perspective, conservativeness is valuable for compiler
writers too: high quality of the language is in the end what motivates
the choice for quality projects, and what in turn motivates the fees for
quality compilers as well.

I don't think that Intel could charge as much as they do, it their
compilers were used for short-lived projects.

>
> /Jorgen
>

[Juha Nieminen]

Paavo Helde <myfir...@osa.pri.ee> wrote:
> They have done this before, this is nothing new. "auto" and ">>" are the
> first examples of considered *and* accepted changes which pop to mind.

In what way has the operator >> changed in such a manner that has made
old code not compile?

[Alf P. Steinbach]

It's about template argument lists, like

foo<bar<41>>

In C++03 you had to write

foo<bar<41> >


Cheers & hth.,

- Alf

[Juha Nieminen]

The question was about code that *stopped* compiling due to the change
in standard, not code that previously didn't compile but now does.

[Ben Bacarisse]

So flip the problem round:

template <int n> struct A { int a[n]; };
...
A< n>>1 > x;

became a syntax error with C++11.

--
Ben.

[Chris Ahlstrom]

Jorgen Grahn wrote this copyrighted missive and expects royalties:

+1

--
Q: What's tan and black and looks great on a lawyer?
A: A doberman.

[Richard]

[Please do not mail me a copy of your followup]

Ben Bacarisse <ben.u...@bsb.me.uk> spake the secret code
<87in8ip...@bsb.me.uk> thusly:

>So flip the problem round:
>
> template <int n> struct A { int a[n]; };
> ...
> A< n>>1 > x;
>
>became a syntax error with C++11.

The workaround is to use A<(n >> 1)> x;
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[Lynn McGuire]

Because I want to convert my calculation engine from F77 to C++. I need
all the speed that I can get as we are still computationally intensive
and threading our calculation engine is a no-go.

Thanks,
Lynn

[Ben Bacarisse]

legaliz...@mail.xmission.com (Richard) writes:

> [Please do not mail me a copy of your followup]
>
> Ben Bacarisse <ben.u...@bsb.me.uk> spake the secret code
> <87in8ip...@bsb.me.uk> thusly:
>
>>So flip the problem round:
>>
>> template <int n> struct A { int a[n]; };
>> ...
>> A< n>>1 > x;
>>
>>became a syntax error with C++11.
>
> The workaround is to use A<(n >> 1)> x;

Yes, but not really the point!

--
Ben.

[Richard]

[Please do not mail me a copy of your followup]

Lynn McGuire <lynnmc...@gmail.com> spake the secret code
<pbl2gb$u5g$1...@dont-email.me> thusly:

>On 4/19/2018 4:03 AM, Jorgen Grahn wrote:
>> On Thu, 2018-04-19, Lynn McGuire wrote:
>>> Interesting only if C++ can generate faster code.
>>
>> Why? Fast code is important, but it's not the only characteristic of
>> a language.
>

>Because I want to convert my calculation engine from F77 to C++. I need
>all the speed that I can get as we are still computationally intensive
>and threading our calculation engine is a no-go.

If your code has intrinsic data parallelism, you might want to
consider CUDA for the GPU.

[Jorgen Grahn]

On Mon, 2018-04-23, Lynn McGuire wrote:
> On 4/19/2018 4:03 AM, Jorgen Grahn wrote:
>> On Thu, 2018-04-19, Lynn McGuire wrote:
>>> "The C++ committee has taken off its ball and chain"
>>>
>>> http://shape-of-code.coding-guidelines.com/2018/04/14/the-c-committee-has-taken-off-its-ball-and-chain/
>>>
>>> “The Committee should be willing to consider the design / quality of
>>> proposals even if they may cause a change in behavior or failure to
>>> compile for existing code.”
>>
>> There's not a lot more detail in the article, though; mostly
>> historical background, and hints about breaking more C compatibility.
>> Any more thoughts about what this would mean in practice?
>>
>>> Interesting only if C++ can generate faster code.
>>
>> Why? Fast code is important, but it's not the only characteristic of
>> a language.

...

> Because I want to convert my calculation engine from F77 to C++. I need
> all the speed that I can get as we are still computationally intensive
> and threading our calculation engine is a no-go.

So you mean "interesting to me only if it means future C++ code will
be able to beat Fortran for certain use cases"? Fair enough, I
suppose.

[Melzzzzz]

Question is why he wants to convert calculation engine to C++...

>
> /Jorgen
>


--
press any key to continue or any other to quit...

[Lynn McGuire]

Because I prefer C++ nowadays. The calculation engine is about 700K
lines of F77 code with 10K lines of C and C++. We cannot use the Intel
Fortran compiler since it has two showstopper bugs that we have run into
so we use the old Watcom F77 compiler for now.

When life slows down a little, we are going to try the Fable F77 to C++
converter on our code:
http://cci.lbl.gov/fable/

Lynn

[Melzzzzz]

So reason for all the fuss is bug in Intel Fortran compiler? Hm, what
about gfortran?

>
> Lynn

[Paavo Helde]

On 24.04.2018 2:58, Lynn McGuire wrote:
> On 4/23/2018 5:57 PM, Melzzzzz wrote:
>> Question is why he wants to convert calculation engine to C++...
>
> Because I prefer C++ nowadays. The calculation engine is about 700K
> lines of F77 code with 10K lines of C and C++. We cannot use the Intel
> Fortran compiler since it has two showstopper bugs

Converting 700K lines of code from one language to another seems like a
daunting task, whatever the tools. What about reporting the bugs to
Intel and waiting a couple of years until they fix them?

[Lynn McGuire]

We ran into a problem there also. Not a bug but a lack of an old
commonly used print extension (carriage control of the device using the
first character printed). So we have yet to finish the port as the
conversion of our code will require some 10,000 lines of code to
changed. But a C++ conversion will require the same conversion so all
work in that direction will be good.

Thanks,
Lynn

[Lynn McGuire]

They fixed one bug (a limit of 300,000 global symbols in the linker) and
we cannot duplicate the second problem in a subset of our source code (a
failure to automatically initialize all local vectors to zero). We are
not giving them our source code.

Thanks,
Lynn

[jacobnavia]

I hope C++ diverges from C as fast as it can.

This would help C language development. Not having to be "C++
compatible", C could devlop in the direction it always had:

Stability
Speed
Simplicity

A language that doesn't fill your brain with computer trivia.

jacob