C++14: Papers

[James Kanze]

Nonsense or not but those dominant positions feel right now about as dominant
as those of Objective-C, Shell script and Perl.

With the major difference that there doesn't seem to be any new
competition. C++ seems to have beat out Ada-95, and in a more
distant past, Objective-C and Modula-3, but since then, there's
not really been any new language which realistically attempts to
replace it. If something new does come along, that is to C++
what Python is to Perl, I'd jump on it, but I don't see it
happening. In the case of C++, the total is simply too large:
in the time it would take to redesign a new language with all of
the expressivity of C++, but clean, simple and elegant, C++ will
have added new functionality that are missing in the new
language.

 

[Alexander Terekhov]

James Kanze wrote:
[...]

With the major difference that there doesn't seem to be any new
competition. C++ seems to have beat out Ada-95, and in a more
distant past, Objective-C and Modula-3, but since then, there's

Just wait till Apple comes up with cool
watch/glasses/TV/fridge/microwave/toaster/whatnot with apps programmed
in Objective-C and it will become number one for sure... see charts at

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

;-)

Not so long ago:

http://www.infoworld.com/d/applicat...ity-boosts-objective-c-language-past-c-197083

"Apple's popularity boosts Objective-C language past C++

Used for building iPad and iPhone apps, Objective-C takes over third
place in Tiobe language survey, knocking C++ to fourth"

regards,
alexander.

 

[osmium]

With the major difference that there doesn't seem to be any new
competition. C++ seems to have beat out Ada-95, and in a more
distant past, Objective-C and Modula-3, but since then, there's
not really been any new language which realistically attempts to
replace it. If something new does come along, that is to C++
what Python is to Perl, I'd jump on it, but I don't see it
happening. In the case of C++, the total is simply too large:
in the time it would take to redesign a new language with all of
the expressivity of C++, but clean, simple and elegant, C++ will
have added new functionality that are missing in the new
language.

That's really sad; I can only hope your analysis is wrong. I remember the
elation I felt as a Fortran programmer when I first used Algol 60. So THIS
is the way the grown ups do it; it was such a rush! C++ is so obviously a
group effort, with no discernable philosophy, the damned thing just grew and
grew and it is still growing. We have ridiculous brevity, '%' means modulo?
Give me a break. And that is mixed with monstrously long identifiers in STL
that would be very much at home in COBOL All that in one language?? . And
in an era in which GUI is THE way to interface with humans, an add on
library is needed to write a real program. Oh, this program is written in
C++ with the whatchamacallit GUI. You three guys leave the room while we
discuss this problem.

Just pathetic, really. This disgusting piece of crap is the best the human
mind can come up with?

 

[Öö Tiib]

Where "other languages" == C?

No difference actually if it is C or not. C interface is just often used
as "language neutral" interface.

C libraries are the glue that holds most of today's computing together.
Do you hear Python or PHP programmers complaining about their
languages incorporating C libraries? No.

Other languages do provide their binding layer to the underlying C (also
often C++) libraries. C++ is somehow too proud that C program "almost
compiles" as C++ so no need for special interfaces. "Write one yourself"
is standard answer. I won't go into depth here about such googled out
codeguru broken joints that one can nothing to do with but to weed out.

C++ has done very well building on its C foundations, what is to be
gained by throwing them away and building a new set of wheels?

No! Do not reinvent wheels constantly. Do not even reinvent the ball
bearings with no end. That is what I mean. I would like if C++ would
officially decide that those wheels are good enough by describing
fitting ball-bearings.

I am generally against such mentality that whatever change is bad;
that C++ is monster; that it has to die and let it to die.
I really like C++11, my impression is that it made so lot of things
simpler and more complete. There are only few things that feel wrong
(like confusingly loose list-initialization). The C++14 proposals
seemed partly fixing the shortcomings of C++11, and partly introducing
base for such new joints.

 

[Martin Ba]

I would go a slightlly different route: stop adding library stuff to the
standard, and instead make them available through Boost or a Boost-like
library aggregator service with a license that authorizes all forms of use.
There is absolutely no need to standardize a component if it's possible to
freely download and install it on any computer, or even store the source
files in the project tree.

What I have been wondering on occasion is whether including all these
great features in the standard will make C++ code *less* portable in the
end.

The bigger and more complex the std-library gets, the more likely it
gets that different vendor implementations would have subtle differences
that would break portability vs. having a single-source library (like
Boost) that uses at least the "same" source code on all platforms.

just a thought.

- Martin

 

[Miquel van Smoorenburg]

With the major difference that there doesn't seem to be any new
competition. C++ seems to have beat out Ada-95, and in a more
distant past, Objective-C and Modula-3, but since then, there's
not really been any new language which realistically attempts to
replace it.

Perhaps http://rust-lang.org/

Mike.

 

[Thomas Richter]

Am 10.04.2013 16:00, schrieb Martin Ba:

What I have been wondering on occasion is whether including all these
great features in the standard will make C++ code *less* portable in the
end.

The bigger and more complex the std-library gets, the more likely it
gets that different vendor implementations would have subtle differences
that would break portability vs. having a single-source library (like
Boost) that uses at least the "same" source code on all platforms.

While I kind of agree, you also hear the opposite here in this forum
from time to time - from people complaining why C++ does not include a
GUI library as part of its standard, for example.

 

[Cholo Lennon]

Just wait till Apple comes up with cool
watch/glasses/TV/fridge/microwave/toaster/whatnot with apps programmed
in Objective-C and it will become number one for sure... see charts at

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

;-)

Not so long ago:

http://www.infoworld.com/d/applicat...ity-boosts-objective-c-language-past-c-197083

"Apple's popularity boosts Objective-C language past C++

Used for building iPad and iPhone apps, Objective-C takes over third
place in Tiobe language survey, knocking C++ to fourth"

I completely agree with someone who posted the following in response to
the article you mentioned:


"Rankings are determined by activity in search engines and other 'buzz'.
So an established language that is well known will have little activity
and have a low ranking by this method. I'm taking this story with a big
grain of salt."


Tiobe is just a partial point of view...

Regards

 

[Victor Bazarov]

[..]
What I have been wondering on occasion is whether including all these
great features in the standard will make C++ code *less* portable in the
end.

The bigger and more complex the std-library gets, the more likely it
gets that different vendor implementations would have subtle differences
that would break portability vs. having a single-source library (like
Boost) that uses at least the "same" source code on all platforms.

just a thought.

By definition, if something in the Standard and *specified*, it can't be
non-portable. Every implementation of the library shall behave in the
expected way, otherwise it can't be called "standard-compliant". And
that's the Committee's task to ensure that whatever is *specified* is
/not/ *under*-specified, which usually means "left to the
implementation", and thus breeds incompatibility. So, banish the
thought, it doesn't do you (or anybody else) any good to worry about
things that don't yet exist.

Subtle difference do exist, and it's OK, as long as they are in respect
to the portions of the behaviour that are actually left un- or
under-specified.

The old (and still true, AFAICT) example of this is virtual functions or
references. How they are implemented (vtbl, readonly pointers) is of no
concern of the Standard. However, if *you* start relying on some
particular implementation of the feature that in the language or library
is left to the implementation, it's not the Standard's fault when you
find your code non-portable...

V

 

[osmium]

Am 10.04.2013 16:00, schrieb Martin Ba:


While I kind of agree, you also hear the opposite here in this forum from
time to time - from people complaining why C++ does not include a GUI
library as part of its standard, for example.

One of the reasons often cited for the failure of Algol 60, was the failure
to include I/O in the standard. (I got exposed to it by my boss, who had
recently returned from Europe, where Algol did have a certain amount of
success.)

ISTM that C++ has only a very constrained I/O without GUI. In a post I made
in another thread, it was meant to be implicit that the three guys who could
leave the meeting, had no background in the "whatchamcallit" GUI.

 

[Jorgen Grahn]

With the major difference that there doesn't seem to be any new
competition. C++ seems to have beat out Ada-95, and in a more
distant past, Objective-C and Modula-3, but since then, there's
not really been any new language which realistically attempts to
replace it. If something new does come along, that is to C++
what Python is to Perl, I'd jump on it, but I don't see it
happening. In the case of C++, the total is simply too large:
in the time it would take to redesign a new language with all of
the expressivity of C++, but clean, simple and elegant, C++ will
have added new functionality that are missing in the new
language.

Or "in the time it would take to redesign a new language with all of
the expressivity of C++, but clean, simple and elegant, the new
language would become no more clean, simple or elegant than C++".

I also get less worried, in a way, when I realize that pretty much
every programmer I know (young and old) still sticks to old ANSI C.
The APIs they work with are all C APIs, and so on. The hunger for the
Silver Bullet language cannot be that great.

/Jorgen

 

[Stefan Ram]

Tiobe is just a partial point of view...

Then show me the other points of view that are based on
such a wide variety of sources observed for so many years.

 

[Stefan Ram]

Or "in the time it would take to redesign a new language with all of
the expressivity of C++, but clean, simple and elegant, the new
language would become no more clean, simple or elegant than C++".

»Within C++, there is a much smaller and cleaner
language struggling to get out.«

Stroustrup, Bjarne. The Design and Evolution of C++. pp. 207.

 

[Nobody]

Then show me the other points of view that are based on
such a wide variety of sources observed for so many years.

The issue isn't the number of sources, but their quality.

Tiobe doesn't represent the actual usage of a language so much as the
derivative of usage with respect to time.

If a language obtains a sudden spike in popularity (e.g. because Apple's
latest iGimmick requires Objective-C and everyone wants in on the
bandwagon), you'll see a spike in "internet buzz" for that language.

The spike will disappear either:
a) when people have actually become familiar enough with the language that
they no longer need to ask about it or evangelise it, and are just
using it regularly, or:
b) when everyone forgets about it and chases a different bandwagon.

Once the spike disappears, it's impossible to tell whether it's because of
a) or b).

 

[Stefan Ram]

The issue isn't the number of sources, but their quality.

»Wide variety« does not mean »large number«.

»Quality« is entirely subject/undefined, unless you give an
operational definition of more specific means how to measure
the quality. Maybe you like to blur things up to the point
where you cannot be proven false anymore.

Tiobe doesn't represent the actual usage of a language

What is »the actual usage of a language« (in terms
of a number that fits in a table)?

How can one measure it?

 

[Öö Tiib]

With the major difference that there doesn't seem to be any new
competition. C++ seems to have beat out Ada-95, and in a more
distant past, Objective-C and Modula-3, but since then, there's
not really been any new language which realistically attempts to
replace it.

With Objective-C the competition is still quite close. Some like
one some other. What are your criteria for competitive?

If something new does come along, that is to C++ what Python is
to Perl, I'd jump on it, but I don't see it happening.

That is too high requirement perhaps. If something is to C that
Python is to Perl then that would be enough to win C++ (that is
about equally popular with C).

In the case of C++, the total is simply too large:
in the time it would take to redesign a new language with all of
the expressivity of C++, but clean, simple and elegant, C++ will
have added new functionality that are missing in the new
language.

I still hope that C++ could be simplified. For example introduce
modules, deprecate '#include'. Deprecate 'inline' too ("exported"
definitions are "inline"). Make it optionally possible to acquire
equivalents of '__FILE__' , '__LINE__' and '__FUNCTION__' of
caller (like class type return value currently already is such
optional hidden parameter in most implementations). Deprecate
#define. As result ... most sane usages for preprocessor and
'inline' removed.

 

[Nobody]

What I have been wondering on occasion is whether including all these
great features in the standard will make C++ code *less* portable in the
end.

The bigger and more complex the std-library gets, the more likely it
gets that different vendor implementations would have subtle differences
that would break portability vs. having a single-source library (like
Boost) that uses at least the "same" source code on all platforms.

If the behaviour is left as "implementation-defined", then it's almost
inevitable that it will differ between platforms.

If the standard dictates the behaviour down to the smallest detail, any
conforming implementation would need to include an OS kernel and
virtualisation layer, because using the platform's native facilities
directly will result in non-conforming behaviour.

Of course, the end result of the latter approach would be that no-one
bothers implementing a conforming implementation, because no-one would use
it. Instead, you'd have a variety of almost-conforming implementations,
each with different conformance/practicality trade-offs.

 

[Martin Ba]

[..]
What I have been wondering on occasion is whether including all these
great features in the standard will make C++ code *less* portable in the
end.

The bigger and more complex the std-library gets, the more likely it
gets that different vendor implementations would have subtle differences
that would break portability vs. having a single-source library (like
Boost) that uses at least the "same" source code on all platforms.

just a thought.

By definition, if something in the Standard and *specified*, it can't be
non-portable. Every implementation of the library shall behave in the
expected way, otherwise it can't be called "standard-compliant". And

And who of the implementers cares enough? It's not like anyone can force
them to be fully standard-compliant.

And, anyway, I was more thinking of bugs in the implementations vs. the
standard-defined-behavior. It doesn't do you any good when the standard
mandates something, but your implementations have not implemented it
correctly and you cannot switch the implementation on a platform on a whim.

I was more thinking of practical portability-problems-count: What is
better? std-defined-behavior and independent implementations, or "one"
open source like implementation that you can use across platforms. I
guess all I can do is lean back and see, and that's what I plan to do.

that's the Committee's task to ensure that whatever is *specified* is
/not/ *under*-specified, which usually means "left to the
implementation", and thus breeds incompatibility. So, banish the
thought, it doesn't do you (or anybody else) any good to worry about
things that don't yet exist.

Once they do exists, it will be too late, won't it?

 

[Stefan Ram]

And who of the implementers cares enough?

Comeau cared enough to implement »export«. And how did they
honour this? By removing »export« from the standard!

I also have not heard about Comeau products for some months.

 

[Rui Maciel]

Then show me the other points of view that are based on
such a wide variety of sources observed for so many years.

The tiobe index is fundamentally meaningless. It builds its rating by
counting search hits on sites such as youtube and amazon.

http://www.tiobe.com/index.php/content/paperinfo/tpci/tpci_definition.htm


It would be silly if someone picked which language would be the foundation
of his programming career by checking which had more hits on youtube.


Rui Maciel