C++14: Papers

[Rui Maciel]

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

How can one measure it?

Searching through the repositories of some software hosting services, such
as sourceforge, google code or github, would be a start.

http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities


Some services even compile some interesting statistics, such as:

https://github.com/languages


Rui Maciel

 

[Bo Persson]

Martin Ba skrev 2013-04-10 16:00:

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.

Boost is definitely NOT using the same source code on all platforms. It
uses tons of configuration macros and workarounds to make the
implementation compile on all supported compilers.

In some of the Boost libraries it is actually hard to find any code at
all without first going through 10 layers of macros and system specific
include files.


Bo Persson

 

[Ian Collins]

IMO, it is data-encapsulation and objects (classes) that make C++ superior
to C. Neither of which require templates.

Until you want a generic object....

 

[Stefan Ram]

Until you want a generic object....

Objects are run-time entities.

Generics are handled by the compiler, they do not exist at run time.

So, there are no »generic objects«.

C has objects. And types like »FILE« encapsulate.

 

[Ian Collins]

Objects are run-time entities.

Generics are handled by the compiler, they do not exist at run time.
Boost.Any?

So, there are no »generic objects«.

I'm sure you know what I mean.

Even simple class templates like the humble auto_ptr are very useful in
kernel land. If you look at all the spaghetti clean up code often found
in C kernel code, you'll see why.

 

[Jorgen Grahn]

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

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

He doesn't really explain what he means by that, but right before that
he writes "I maintain that C++'s type system and semantics are cleaner
than its syntax". My guess is he's thinking of the compromises taken
while basing the language on C. Well, it was necessary, and I believe
it still is.

/Jorgen

 

[Ian Collins]

_want_ and _need_ are two different things.

One can certainly write object-oriented code without a generic object.

One can also apply the same argument to data encapsulation and objects.

In my experience with drivers and other kernel modules, heterogeneous
resource management is more of an issue than it is in user space. One
significant benefit C++ can bring in this area is removal of all the "if
(some error) goto end" spaghetti. Yes you could write a small class for
each resource type, but why bother when we have templates?

 

[Rui Maciel]

C doesn't enforce data encapsulation (public/private/protected). C
doesn't have virtual functions (polymorphism).

C doesn't have explicit support for virtual functions in its core language.

Having said that, if anyone is willing to put in the legwork, function
pointers are all that is needed to simulate virtual functions.


Rui Maciel

 

[88888 Dihedral]

Rui Macielæ–¼ 2013å¹´4月11日星期四UTC+8上åˆ5時38分49秒寫é“：

Scott Lurndal wrote:







C doesn't have explicit support for virtual functions in its core language.

Don't you use hookers or so called functors to wrap your
platform dependent part in C?

Having said that, if anyone is willing to put in the legwork, function

pointers are all that is needed to simulate virtual functions.

I'll give an example as follows:
If the information about the platform is well collected
first, then a well behavior functor can be set
before entering the inner loop of a time critical task.

Don't you get the notion about the run-time behaviors?

 

[Öö Tiib]

Objects are run-time entities.

Generics are handled by the compiler, they do not exist at run time.

So, there are no »generic objects«.

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.

 

[Rui Maciel]

When a new version of some C++
compiler suite comes out (not to speak about a new C++ implementation!),
the existing Boost libraries often cease to compile or work with it, and
there is some time window before the issues (hopefully) get fixed in the
next Boost versions. This is something the standardization is supposed to
get rid of.

A standard doesn't help here, as well.

Look at how the people at Microsoft decided to develop their "learn to
program for windows in C++" bit[1]. C++'s fundamental types aren't used,
and in alternative Microsoft decided to define new types which share their
name with C++'s fundamental types, minnus the capitalization, and explicitly
tell the users that they are not interchangeable.

This doesn't stop on fundamental types: it only starts from there. For
example, instead of using std::string, let alone the STL, they've repeatedly
chose to use anything else.

This is being done in the same organization and maybe even by the same
people who work with C++'s standard committee to open the door to an
avalange of bloat which apparently they have no intention to implement.


Rui Maciel

[1] http://msdn.microsoft.com/en-
us/library/windows/desktop/ff381399%28v=vs.85%29.aspx

 

[guinness.tony]

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.

comeaucomputing.com has been down for some months.

Greg tweeted some status updates here:

https://twitter.com/comeaucomputing

 

[Spike]

Look at how the people at Microsoft decided to develop their "learn to
program for windows in C++" bit[1]. C++'s fundamental types aren't used,
and in alternative Microsoft decided to define new types which share their
name with C++'s fundamental types, minnus the capitalization, and explicitly
tell the users that they are not interchangeable.

This doesn't stop on fundamental types: it only starts from there. For
example, instead of using std::string, let alone the STL, they've repeatedly
chose to use anything else.

The title can be deceiving, I know, but that series basically hasn't
anything to do with C++, it is about a "C" API, born two decades ago and
not really changed ever since.

S.

 

[Martin Shobe]

On 4/11/2013 2:29 AM, Rui Maciel wrote:
[snip]

Look at how the people at Microsoft decided to develop their "learn to
program for windows in C++" bit[1]. C++'s fundamental types aren't used,
and in alternative Microsoft decided to define new types which share their
name with C++'s fundamental types, minnus the capitalization, and explicitly
tell the users that they are not interchangeable.

This doesn't stop on fundamental types: it only starts from there. For
example, instead of using std::string, let alone the STL, they've repeatedly
chose to use anything else.

That's a windows API tutorial, not a C++ one. So, considering that those
interfaces (and the types they use) predate C++, and also the need for
them to work in C (and a host of other languages), is it really that
surprising?

This is being done in the same organization and maybe even by the same
people who work with C++'s standard committee to open the door to an
avalange of bloat which apparently they have no intention to implement.

Which parts of C++ are they not intending to implement?

Martin Shobe

[1]

http://msdn.microsoft.com/en-us/library/windows/desktop/ff381399(v=vs.85).aspx

 

[Victor Bazarov]

[..]

[..]
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?

Not really.

First off, the Standard is not set in stone, it's a document that can
and does change. If something in it is not to your liking, convince
enough people and a change can and will be made.

Second, the life is full of trade-offs (surprise!), so if something is
not up to your [personal] liking, you don't have to use it. If it is
your employer that insists on your using something you don't like,
change the employer, et cetera.

Third, let's take some alternatives that are still open to us in some
cases. Let's suppose nothing is standardized. Everything is specific
to the implementation or to the platform. No code is then portable
(unless by accident). Is that viable? I don't think so. Let's now
suppose everything is standardized to a minute detail. The code *you*
write is portable to no exception. You "write once, compile anywhere"
regardless of what you're programming (and I do mean *anywhere* where it
is *already, as of now*, not just on a few choice platforms, fewer every
year). Is it attainable? Probably not. Implementors will have really
hard time with it (harder and harder as we go along). Now, using the
mean value theorem essentially gives us that, if on both ends of the
continuum the values (in this case usability) are 0 (either from
uselessness from our POV or inability to implement a compiler/library
satisfactorily), then either the entire range is useless (no sense to
even attempt specifying anything), or there has to be at least *one
point* in the middle where the value (usability) is *maximized*. And
that is what the efforts are expended to attain. We're trying to find
the best of both worlds, so to speak; not too hard to implement, and not
impossible to use.

Now, with the changing technologies, with some elements of the computer
capabilities becoming more widespread, the target point keeps moving.
And that's why new elements come into view, and admitted to being
discussed. Dismissing them *before ever trying to specify them*, just
based on a notion that, if mistakes are made in the implementation (some
time after the specification has been created), or if when using the
implementations we (even later than the Standard) discover that
something still is not to our liking, is IMNSHO meritless. It's the
same as saying that we shouldn't start on a journey just because there
is a possibility the journey can lead us to our death! What kind of
philosophy is that?

V

 

[Stefan Ram]

Is it attainable? Probably not. Implementors will have
really hard time with it (harder and harder as we go along).

People took former implementations, like Pet 2001, Amiga, or
HP 48 as standards and wrote emulators for it, exactly to
that minute detail: emulating special hardware, video-
timing, sound-hardware, device interfaces, and everything.

Thanks to those emulators, software for the Pet 2001, Amiga,
or HP 48 is now most portable, because those emulators exist
for most operating systems. Ironically, this code, which was
written not at all with portability in mind, nowadays is
more portable that code written in today's »portable« languages.

 

[Victor Bazarov]

People took former implementations, like Pet 2001, Amiga, or
HP 48 as standards and wrote emulators for it, exactly to
that minute detail: emulating special hardware, video-
timing, sound-hardware, device interfaces, and everything.

Thanks to those emulators, software for the Pet 2001, Amiga,
or HP 48 is now most portable, because those emulators exist
for most operating systems. Ironically, this code, which was
written not at all with portability in mind, nowadays is
more portable that code written in today's »portable« languages.

It's interesting. So, your suggestion, then, is to abandon the
standardization efforts, write non-portable code, all in hopes that one
day there will be emulators to run all that non-portable code on all
systems where the emulators have been implemented...

V

 

[Martin Ba]

On 4/10/2013 10:00 AM, Martin Ba wrote:
[..] [..]
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?

Not really.
...
Third, let's take some alternatives that are still open to us in some
cases. Let's suppose nothing is standardized. ... Let's now
suppose everything is standardized to a minute detail. ... We're trying to find
the best of both worlds, so to speak; not too hard to implement, and not
impossible to use.

... Dismissing them *before ever trying to specify them*, just
based on a notion that, if mistakes are made in the implementation (some
time after the specification has been created), or if when using the
implementations we (even later than the Standard) discover that
something still is not to our liking, is IMNSHO meritless.

FWIW, I found the very original post (C++14 papers -- "kitchen sink ...
sanitary network ...") rather stupid.

I *don't* think that C++11 contains too much by *any* account, and
already it seems that implementors are struggling to get everything in
it implemented in a decent time frame.

I really do look forward to more useful stuff in C++ "out of the box",
but let's just hope the the quality doesn't suffer from too much in too
little time.

cheers,
Martin

 

[James Kanze]

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

That is, I think, the real question. Until it has been
answered, all of the sites which pretend to measure which
language is most used are just showing their incompetence (or
dishonesty, perhaps, in some cases).

All I claim is that there is a large class of applications for
C++ is more or less the only solution. Today (and I often
wonder why Ada 95 didn't get more consideration). It wasn't
necessarily true in the past, and perhaps it won't be true in
the future, although I don't see any potential concurrent being
developped at the moment.

That doesn't mean that it's the only language, or the best
language for everything. Where I work, we use Excel,
Mathematica, Python and C# as well, not to mention specialized
languages like SQL, or individual choices for local tools (e.g.
I'll often use bash, or even the Bourne shell, with sed and
awk, and the rest for small, quick tools). All of the real work
is done in C++, but there's a lot of "glue" as well.

 

[James Kanze]

I can sympathize with most of your complaints. However:

[...]

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.

Very few programs actually interface directly with humans. And
C++ is probably not the best choice for a light weight GUI
client.

(Actually, I'm not really sure what I mean by "very few
programs". People are constantly recreating new GUI interfaces
to conform to the look of the day. The real work will still be
done by the C++ program behind them, but that's one program,
probably originally written some years ago, but still evolving,
versus five or ten different programs, each written in maybe
three months, then thrown out when the next one comes along.)