C++14: Papers

[James Kanze]

One could argue that Java is the "python to perl" for C++. It is much
cleaner (or was prior to java 7) than C++, more maintainable and more
readable.

Java's "cleaner" because it doesn't try to address many of the
issues C++ addresses. It's actually an interesting case: where
C++ has a less than optimal solution to a problem, Java solves
it by pretending that the problem doesn't exist, and banishing
all solutions to it. Thus, for example, in a large project, you
definitely want to keep the public interface definition (the
class definition) is a separate file from the implementation
code. The C++ solution is probably about the worst one could
conceive of: textual inclusion of the class definition, the
requirement that private data members be defined, etc. But
Java's answer wasn't to create a better solution; it was to
totally forbid the practice, even though it is clearly
desirable. (I know, there are work-arounds: in Java, you define
an interface or an abstract class, with static factory functions
to construct the actual objects. It can usually be made to
work, but it's not really flexible enough.)

The obvious downsides are bytecode and non-determinism which
are antithetical to many classes of problems that are solved by C++.

I don't think byte code has much to do with it (although it does
mean that you can't test your program in all of the possible
environments in which it might run). And Java is actually less
non-deterministic than C++---you need garbage collection to be
truly deterministic, for example.

 

[James Kanze]

]
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++".

There's something to that, but I think it's more: in the time
it would take to design a new language with all of the
expressivity of C++, but clean, simple and elegant, our
understanding of what is required in the language will have
evolved so that the new language would not meet the new
criteria.

The reason for C++'s success is certainly not its simplicity or
its elegance. The real reason, I'm convinced, is Bjarne's (and
now the committee's) decision to never close a door, even when
it seems only to open to poor programming practice at the time.
When I was first learning C++, I thought it horrible, compared
to Modula 3. Looking at Modula 3 today, however... There's so
many things you can't do in it, that you can in C++.

Other reasons may be more or less serindipity. I don't think
that anyone really realised the power of destructors when they
were invented, and I'm sure that templates weren't originally
designed with template meta-programming in mind.

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.

C is a very good language for defining API's, because it is so
much like a portable assembler. For the same reason, no sane
programmer would use it in a large application.

 

[James Kanze]

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

Actual use. Maybe I'm not looking in the right places, but I
don't see any large scale applications being developed in
Objective-C. It's use seems to be limited to small "apps" for
one particular system.

The fields I know best are network management and investment
banking. In both cases, the engines which actually do the work
are written almost exclusively in C++. In the case of
investment banking, the absense of Objective-C is very
significant, because ten or fifteen years ago, there was a large
body of code in Smalltalk, and one would think that Objective-C
would be the natural evolution from there, much more so than
C++. And there was a significant body of code in Objective-C.
It turned out (at least in the one case where I know something
of the history) that as the individual programs became more and
more complex, Objective-C became less and less adapt.
Objective-C is (probably---I don't have any actual experience
with it) better than C++ for creating totally new, experimental
implementations of small, interactive software. C++ is superior
for large, stable applications which need to be maintained over
time.

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).

I see very few significant *new* applications written in C.
About the only exception is the Linux kernel, which I'm not sure
I'd consider a good example. (The Python interpreter would
perhaps be better. It's 100% C, and it does prove that you can
write clean and maintainable code in C. But it's really pretty
small, compared to most applications I work on.)

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.

Now that we have threading, modules and garbage collection are
the two things missing in the language itself. Which is
surprising if you realize that both were present and working in
Modula 3, 15 or more years ago. It's not as if the solutions
aren't known. (Although the way C++ uses pointers, inherited
from C, makes garbage collection more difficult than in other
langauges.)

 

[Stefan Ram]

in a large project, you definitely want to keep the public
interface definition (the class definition) is a separate
file from the implementation code. ....
Java's answer wasn't to create a better solution; it was to
totally forbid the practice

file »Interface.java«:

public interface Interface { void f(); }

file »Implementation.java«:

public class Implementation implements Interface { public void f(){} }

In a large project, you definitely want to have a
doumentation for each interface and each abstract method.
C++'s answer was to totally ignore the problem, while Java
has JavaDoc, so a real Java interface file looks more like:

Interface.java

/** This interface ... */
public interface Interface
{
/** This method ... */
void f(); }

The Java standard library even defines standard interfaces.

 

[woodbrian77]

Java's "cleaner" because it doesn't try to address many of the

issues C++ addresses. It's actually an interesting case: where

C++ has a less than optimal solution to a problem, Java solves

it by pretending that the problem doesn't exist, and banishing

all solutions to it. Thus, for example, in a large project, you

definitely want to keep the public interface definition (the

class definition) is a separate file from the implementation

code. The C++ solution is probably about the worst one could

conceive of: textual inclusion of the class definition, the

requirement that private data members be defined, etc. But

Java's answer wasn't to create a better solution; it was to

totally forbid the practice, even though it is clearly

desirable.

What I think was even more desirable to the Java guys
was control and money. Their approach made it more
difficult for small companies with good ideas to be
able to put their ideas out there and compete with Sun.
C++ allows more flexibility in that regard.


Brian
Ebenezer Enterprises - John 3:16.
http://webEbenezer.net

 

[James Kanze]

The term "generic object" usually comes up with type erasure. C++ lacks
something there; the "concepts" proposal was too complex.
Currently only few things like std::function are sort of generic objects
(you do not know if it is function, custom functor class, lambda or
the thing returned by std::bind so it is pretty generic). Ian probably
meant just handling pile of object in generic way, without such type
erasure.

The term "generic object" is considerably older than type
erasure. Type erasure is only one means of implementing generic
objects. Not really one of the best, either.

 

[James Kanze]

On 4/11/2013 2:29 AM, Rui Maciel wrote:
[snip]
Which parts of C++ are they [Microsoft] not intending to implement?

Templates? For the moment, they've implemented something sort
of similar, but they haven't implemented C++ templates, as
defined in C++98 (and C++03 and C++11).

Earlier, they refused to implement export, and pushed for its
removal (which they obtained).

Compared to, say, 10 years ago, they've definitely improved.
But they've still got a way to go.

 

[Öö Tiib]

Actual use. Maybe I'm not looking in the right places, but I
don't see any large scale applications being developed in
Objective-C. It's use seems to be limited to small "apps" for
one particular system.

The fields I know best are network management and investment
banking. In both cases, the engines which actually do the work
are written almost exclusively in C++. In the case of
investment banking, the absense of Objective-C is very
significant, because ten or fifteen years ago, there was a large
body of code in Smalltalk, and one would think that Objective-C
would be the natural evolution from there, much more so than
C++. And there was a significant body of code in Objective-C.
It turned out (at least in the one case where I know something
of the history) that as the individual programs became more and
more complex, Objective-C became less and less adapt.
Objective-C is (probably---I don't have any actual experience
with it) better than C++ for creating totally new, experimental
implementations of small, interactive software. C++ is superior
for large, stable applications which need to be maintained over
time.

Yes, seems that Objective-C is not used for making such network/web
servers. May be it lacks suitable libraries. Its original design goals
seemed quite similar to C++ only that it was closer to Smalltalk.

I see very few significant *new* applications written in C.
About the only exception is the Linux kernel, which I'm not sure
I'd consider a good example. (The Python interpreter would
perhaps be better. It's 100% C, and it does prove that you can
write clean and maintainable code in C. But it's really pretty
small, compared to most applications I work on.)

What you mean by *new*? C has been used as major tool for writing
quite fresh things. For example git and SQLite are both written in C
are very popular and were both first published this century if I'm
not mistaken. You can indeed say that both revision control and SQL
are ideas from 1970 so "not new".

Now that we have threading, modules and garbage collection are
the two things missing in the language itself. Which is
surprising if you realize that both were present and working in
Modula 3, 15 or more years ago. It's not as if the solutions
aren't known. (Although the way C++ uses pointers, inherited
from C, makes garbage collection more difficult than in other
langauges.)

That was what was surprising about OP, few small cosmetics and
fixes were called whole "sanitary network". With C++ I would like even
bigger steps. Python for example seems to use a symbiosis of reference
counting and garbage collection behind scenes and also feels sometimes
better integrated with popular C and C++ "modules" than C++ itself is.

 

[Rui Maciel]

That was what was surprising about OP, few small cosmetics and
fixes were called whole "sanitary network".

By your comment, you clearly haven't even browsed through the proposals.
Here's a bit of information to try to dispel your misconceptions.

C++14 was announced as a bug fix release, similar to C++03. In spite of
that, you can find among the proposals listed so far submittions to:

- boost:ptional
- support for an unstandardized API (OpenMP) to the standard
- yet another array container (DynArray) to the standard
- pipelines
- a brand new operator to be used to swap values, as an alternative to
simply using std::swap() or writing a function that does that.
- SIMD support.
- concepts lite
- add support for exit strategies in for loops
- add an algorithm to split strings
- add a database interface


This is a small subset of all the proposals which have been announced,
proposed to a process intended to fix problems found in a previous release.

Bearing this in mind, does any of these proposals fit your description of
being "few small cosmetics and fixes"?

At least try to glance at the stuff you are commenting on.


Rui Maciel

 

[Martin Ba]

On 4/11/2013 2:29 AM, Rui Maciel wrote:
[snip]
Which parts of C++ are they [Microsoft] not intending to implement?

Templates? For the moment, they've implemented something sort
of similar, but they haven't implemented C++ templates, as
defined in C++98 (and C++03 and C++11).

I didn't notice anything missing from VC++ when using templates. Most of
Boost seems to manage to compile fine too. (yes, not everything C++11 is
in there yet.)

Earlier, they refused to implement export, and pushed for its
removal (which they obtained).

I dunno if MS pushed, but Herb Sutter (of MS) repeatedly claimed in
public that EDG -- AFAIK the only company to fully implement export --
was also in favor of removing it from the standard.

cheers,
Martin

 

[Öö Tiib]

The term "generic object" is considerably older than type
erasure. Type erasure is only one means of implementing generic
objects. Not really one of the best, either.

What are the better ways? Some sort of "variant", "any" or 'union'?

 

[James Kanze]

What are the better ways? Some sort of "variant", "any" or 'union'?

I think I missed the second word in "generic object". Generics
have been around for years, and don't need type erasure.
"Generic objects", on the other hand, are something to be
avoided, at least in languages with some sort of static typing.
(In the early days of C++, there were some who did try to
implement the "everything derives from Object" philosophy, with
boxing for the predefined types. Experience showed that it
wasn't a good idea. At all.)

 

[James Kanze]

On 4/11/2013 2:29 AM, Rui Maciel wrote:
[snip]
Which parts of C++ are they [Microsoft] not intending to implement?

Templates? For the moment, they've implemented something sort
of similar, but they haven't implemented C++ templates, as
defined in C++98 (and C++03 and C++11).

I didn't notice anything missing from VC++ when using templates.

You mean, except the fact that they don't implement them as they
are defined in the standard. They don't understand dependent
names, for example, which is a fundamental aspect of standard
templates.

Most of Boost seems to manage to compile fine too.

You *can* work around the differences, and Boost does a lot of
working around. It does make writing portable code extremely
difficult.

[...]

I dunno if MS pushed, but Herb Sutter (of MS) repeatedly claimed in
public that EDG -- AFAIK the only company to fully implement export --
was also in favor of removing it from the standard.

I think you missed most of the history. Herb Sutter was the one
who started the movement against export, writing that it
couldn't be implemented (when EDG was well along the way to
implementing it). EDG finally accepted the removal, mainly,
I suspect, because they wanted unity in the C++ community, and
Microsoft wasn't going to let up until they got what they
wanted. (On this issue---since Herb Sutter has been at
Microsoft, they've generally been quite understanding with
regards to building concensus, and willing to adapt to the
prevailing consensus, rather than force issues. Why they felt
so strongly with regards to export, I don't know.)

 

[Stefan Ram]

I think I missed the second word in "generic object".

Objects are run-time entities. If there would be such a
thing as a »generic object«, on would be able to write a
detector for it:

bool isgeneric( void * const object ){ return ???; }

 

[Jorgen Grahn]

....
In a large project, you definitely want to have a
doumentation for each interface and each abstract method.
C++'s answer was to totally ignore the problem,

Not really. C++ supports comments, which solves the problem.
It doesn't standardize extraction of documentation, but that
problem is not as urgent in a language with header files.

(Based on my experience not with Java but with Python. In C and C++ I
rarely spend time extracting the (Doxygen) documentation; in Python I
do 'pydoc Foo' all the time because I can't get that overview in any
other easy way.)

while Java
has JavaDoc, so a real Java interface file looks more like:

/Jorgen

 

[Balog Pal]

Templates? For the moment, they've implemented something sort
of similar, but they haven't implemented C++ templates, as
defined in C++98 (and C++03 and C++11).

Err, do you mean their reluctance to implement two-phase lookup, and use
single lookup in the instantiation context? Which is WAYS more intuitive
in the (actually pretty rare) cases that it creates a difference?

2PhL is something I ask as a joke, or is someone claims mastery in C++
-- would not hold my breath to get a precise answer except from a
handful of people.

Earlier, they refused to implement export

Just as the whole world except a single group, that eventually also
asked for its pull from the standard.

, and pushed for its
removal (which they obtained).

*Everyone* pushed for that actually.

Compared to, say, 10 years ago, they've definitely improved.
But they've still got a way to go.

I just talked with Herb hours ago, he strictly refused to disclose
anything about plans, but I had the impression they are taking up
serious speed, and might release C++14 features and the concepts lite TS
about same time as others.

My practical problem with MS is not their new feature release speed but
that they are routinely closing admitted code generation bugs with NOFIX
and the race condition-ridden unstable IDE.

 

[Balog Pal]

C++14 was announced as a bug fix release, similar to C++03. In spite of
that, you can find among the proposals listed so far submittions to:

As I understand it C++14 will be a MINOR (rather than bugfix as '03) and
'17 a MAJOR, followed by a similar 3-3 year cycles.

As it looks now chances are good we'll see a ton of cool new stuff
around '14. Stay tuned this Friday and Saturday.

 

[Balog Pal]

29 AM, Rui Maciel wrote:
[snip]
Which parts of C++ are they [Microsoft] not intending to implement?
Templates? For the moment, they've implemented something sort
of similar, but they haven't implemented C++ templates, as
defined in C++98 (and C++03 and C++11).

I didn't notice anything missing from VC++ when using templates.

You mean, except the fact that they don't implement them as they
are defined in the standard. They don't understand dependent
names, for example, which is a fundamental aspect of standard
templates.

You mean the *in*dependent names, and not *bind* them early?

I think it would help a lot if you showed an example on the difference
of behavior so everyone could see it exposed for good.

You *can* work around the differences, and Boost does a lot of
working around. It does make writing portable code extremely
difficult.

As I looked at boost code most workarounds belong to other compilers.

The more realistic differences I'd expect related to SFINAE, but I'd bet
it's not realy common to get it right all the way. ;-o

[...]

I dunno if MS pushed, but Herb Sutter (of MS) repeatedly claimed in
public that EDG -- AFAIK the only company to fully implement export --
was also in favor of removing it from the standard.

I think you missed most of the history. Herb Sutter was the one
who started the movement against export, writing that it
couldn't be implemented (when EDG was well along the way to
implementing it).

For cartain definition of "started". I doubt you can find anyone
involved with the C++ standard to call export other then "catastrophic
failure".

EDG finally accepted the removal, mainly,
I suspect, because they wanted unity in the C++ community,

Yeah, pretty close. As the committee considered waiting for them to ask
as the only politically correct thing (using the original meaning) [that
is what FG. told me a few days ago.]

 

[Martin Shobe]

On 14.04.2013 17:34, James Kanze wrote:
29 AM, Rui Maciel wrote:
[snip]
Which parts of C++ are they [Microsoft] not intending to implement?

Templates? For the moment, they've implemented something sort
of similar, but they haven't implemented C++ templates, as
defined in C++98 (and C++03 and C++11).

I didn't notice anything missing from VC++ when using templates.

You mean, except the fact that they don't implement them as they
are defined in the standard. They don't understand dependent
names, for example, which is a fundamental aspect of standard
templates.

You mean the *in*dependent names, and not *bind* them early?

I think it would help a lot if you showed an example on the difference
of behavior so everyone could see it exposed for good.

See

http://www.codeproject.com/Articles/229460/Dependant-Name-Hell

I didn't verify with the standard that those situations require
diagnostics, but I suspect they do. (They also fixed the fourth one in
2010 and Microsoft says (but I haven't verified) that the third one was
fixed in 2012.

[snip]

Martin Shobe

 

[Balog Pal]

See

http://www.codeproject.com/Articles/229460/Dependant-Name-Hell

I'd guess these are NOT the examples James implied. We know for long
that some compilers are not that pedantic and accept sensible code
instead of rejecting it, like the missing typename that is mandated to
help the compiler (most likely introduced to support implementation of
export that is since gone), but the compiler already knows that without
help. That typename thing was a very frequent question at some time,
it seemed everyone keeps stumbling on it and comes to forum asking WTF,
then being educated on the standard way, and then say WTF the standard
was thinking really. I can't really blame them.

And you're only hit by the issue porting code away -- even then by just
a minor nuisance as pasting the error message in google promptly gives
you the fix.

I didn't verify with the standard that those situations require
diagnostics, but I suspect they do. (They also fixed the fourth one in
2010 and Microsoft says (but I haven't verified) that the third one was
fixed in 2012.

Extensions that accept code that is otherwise ill-formed is way too
common, and we all use them. For good. The problematic cases of standard
deviation are ones when well-formed code has different behavior.

So a difference in name binding may well result in a different function
called than the expected one. If you wrote your code with 2phl in mind
really, you may get hit if in the instantiation context more functions
become viable and get selected instead of yours. Potentially it's a damn
serious issue. But my take on it that the actual situation is not
likely, and if happens the program was already neck-deep in shit for
other issues. (that's not a claim just a guess.) I'd welcome an example
that shows good programming practice and suffers from the discussed
deviation.