C++14: Papers

[Öö Tiib]

But the design of a programming language is outside of your thinking ability?
Nothing wrong with that--not everyone is cut out to do that kind of thing.
Perhaps you are more of a programmer which works under the direction of others
who tell you what to program, how to program it and what language to use?

Most experienced C++ users do carve that ideal programming language
out of C++. It is done by not using the features that they feel do not belong
to a good language, by using rest of the features with limitations (see FAQ about
coding standards) and by writing reusable libraries, static code analyzers and code
generators that add features that they feel as being missing from C++.

In sense, they do not dream about having thinking ability. They do use their
thinking ability for moving things forward. A special compiler family (CLang)
has been written to support that process and it is quite popular. Whining
that the tools that you have are shitty indicates bad engineering skills.

 

[Tony]

Most experienced C++ users do carve that ideal programming language
out of C++. It is done by not using the features that they feel do not belong
to a good language, by using rest of the features with limitations (see FAQ about
coding standards) and by writing reusable libraries, static code analyzers and code
generators that add features that they feel as being missing from C++.

I used to do that also. Eventually one gets to the point where they realize they
have been "throwing good money away after bad", and become actionable and do
something about it. C++ is a good learning exercise and stepping stone. Consider
that just by using it for a period of time, one always thinks of ways that it
could have been better, what is wrong with it, and the like. IOW, it spawns
programming language designers! Chalk one up for C++.

Of course, those easily satisfied and not highly demanding may find C++ entirely
adequate. You do, right? Why you feel compelled to take a defensive position and

In sense, they do not dream about having thinking ability. They do use their
thinking ability for moving things forward. A special compiler family (CLang)
has been written to support that process and it is quite popular. Whining
that the tools that you have are shitty indicates bad engineering skills.

Sounds like more C++ fanboyism to me!

 

[Tony]

By all means discuss some and your proposed solutions. All you've added
to the discussion so far is noise.

I can see that the concepts are beyond a lot of you, so forget it. This is a
PROGRAMMING/PROGRAMMER group--my bad for not being a "heads-down coder type".

 

[Öö Tiib]

I used to do that also. Eventually one gets to the point where they realize they
have been "throwing good money away after bad", and become actionable and do
something about it. C++ is a good learning exercise and stepping stone. Consider
that just by using it for a period of time, one always thinks of ways that it
could have been better, what is wrong with it, and the like. IOW, it spawns
programming language designers! Chalk one up for C++.

It is normal to have desire to improve your tools or to search for better tools.
When something is complete and done in best possible way then the evolution
stops at that spot.

Of course, those easily satisfied and not highly demanding may find C++ entirely
adequate. You do, right? Why you feel compelled to take a defensive position and
try to get others to accept your personal practices is <something>.

You said that there were your personal practices as well. C++ is not adequate
for everything. It is useful for lot of things. The programming languages that I use
most actively are Python, C++ and Javascript. On some platforms I use C. I do not
think that one programming language can replace all of them. I try to solve
problems of people with best fitting tools that I know or can make. I am not sure
why I should pose as being someone "highly demanding" here.

One can express faulty logic and nonsense in any programming language exactly
as easily as in any spoken language. To make it hard you have to invent a language
that is on higher level than spoken languages are.

 

[woodbrian77]

and several million others can feed their families. What's your point?

The world is a more dangerous place than it used to be.
What was true 30 years ago about employment is fading
today. Millions know they will be fortunate to walk away
with a pink slip from their current position.

 

[Ike Naar]

I live in the real world.

So does everybody else.

 

[Ian Collins]

So does everybody else.

Except "Tony"

 

[Tony]

Except "Tony"

That's what I get for "blaspheming" C++ I guess.

 

[Joshua Maurice]

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.

I work at a company that regularly does Java and C++, and I feel that
one of the best advantages of Java over C++ is it's amazing and big
standard library. (Not to say that Java is better than C++.) In C++,
it seems to be the default in many places to roll your own, or hope
there's a free library online that has a compatible license that also
happens to run on all of the platforms you care about. Downloading a
third party library, configuring it, and integrating it is nontrivial,
unlike using Java's standard library which is trivial.

I'm still torn though, because I see arguments on both sides. Ex: If
you put it in the standard, and every distribution implements it like
Java has done, then it's available everywhere (or at least everywhere
where there's a JVM). Counter: Everyone may not implement it. I think
that's one of the interesting points that Java has - because it's
under copyright but a very liberal license, if you try to call
yourself Java without implementing the standard, then you get sued. As
long as we have a mostly benevolent dictator or governing
organization, that's a great thing. If the copyright ever moves to an
evil dictator, then it's bad. Without that benevolent dictator, one
can make an argument that the standard wouldn't be fully and correctly
implemented everywhere. I think we've seen this happen with C++
especially on Windows. The windows compiler implements most of C++
correctly, but for example: last I checked, it doesn't do proper
templates and it's doesn't do proper covariant return types for
multiple virtual inheritance.

I suspect the open source spirit would doom any attempt at using
copyright as an enforcement mechanism of the standard, so I don't
know. I still say that a major selling point of Java is it's amazingly
big and useful and correct and portable standard library.

 

[Stefan Ram]

I work at a company that regularly does Java and C++, and I feel that
one of the best advantages of Java over C++ is it's amazing and big
standard library.

See also:

http://www.purl.org/stefan_ram/pub/c++_standard_extensions_en

 

[Jorgen Grahn]

I work at a company that regularly does Java and C++, and I feel that
one of the best advantages of Java over C++ is it's amazing and big
standard library. (Not to say that Java is better than C++.) In C++,
it seems to be the default in many places to roll your own, or hope
there's a free library online that has a compatible license that also
happens to run on all of the platforms you care about.

Python and Perl versus C and C++ in my case, but yes it's a difference.

And not only is it like that, but I seem to happy about it! Reinventing
custom wheels, not being locked into an unsuitable framework, and so on.

Sometimes this worries me -- after all I get paid to get things done.
Long-term productivity effects should decide if I use lots of canned
code, not just how fun it is.

On the other hand it's offputting hearing about Java people memorizing
new frameworks all the time, and seeing the stacktraces some of that
software produces (the one from Eclipse I'm staring at right now is 50
levels deep, and I'm sure I've seen 100 and more).

Downloading a
third party library, configuring it, and integrating it is nontrivial,
unlike using Java's standard library which is trivial.

It's slightly different on Linux. There are large functional areas where
- there is a well-known library
- a sane version has already been integrated by the distribution
- there's at least security support
- the license is known and most likely one of GPL, LGPL, or something
more permissive

[snip]

/Jorgen

 

[Joshua Maurice]

And not only is it like that, but I seem to happy about it! Reinventing
custom wheels, not being locked into an unsuitable framework, and so on.

Sometimes this worries me -- after all I get paid to get things done.
Long-term productivity effects should decide if I use lots of canned
code, not just how fun it is.

I don't understand this. In C and C++, if we added something like
sockets to the standard library, that doesn't stop you from rolling
your own. I'd assume the system calls would still be there, and the
old APIs would probably survive for forever as well. This doesn't make
any sense to me. Do you think that pthreads is going anywhere because
C and C++ have both standardized a new threading API? Am I missing
something?

Even in Java, if I don't like the way Java does something in a
standard library, I can use JNI to do it my way if I really needed to
or wanted to. (At least for most cases.)

 

[Jorgen Grahn]

I don't understand this. In C and C++, if we added something like
sockets to the standard library, that doesn't stop you from rolling
your own. I'd assume the system calls would still be there, and the
old APIs would probably survive for forever as well. This doesn't make
any sense to me. Do you think that pthreads is going anywhere because
C and C++ have both standardized a new threading API? Am I missing
something?

Yes -- that I wasn't talking about growing the standard library or not;
I was talking about my own (and others') reluctance to use ready-made
components, no matter where they come from.

I deliberately avoided entering the "should the standard library be
big or small?" discussion.

/Jorgen

 

[Jorgen Grahn]

So does everybody else.

(Late reply, and I haven't followed the whole thread so I lack some
context.)

It's still a useful distinction. There's a conflict between

- Getting things done short-term, earning a living and solving actual
problems -- "problems" being defined as something, when you fix it,
people are happier for it.

- Seeing ways to make this easier long-term by using different
technology, although you cannot be sure until you've tried it, and
it would have negative effects short-term.

- Having fun with new technology, feeling modern and cool or building
a better-looking CV ... things which are beneficial to /you/ but not
necessarily to whoever is paying you.

- Being content with knowing and using your current tools well,
like the professionals in older days.

I understood "live in the real world" as being focused on the the
/usefulness/ aspect of work, possibly rather short-term.

People and teams have different tendencies. I've worked in very
conservative teams, and I've worked with people who are really mostly
interested in the "fun" aspect. I've worked with people who resist
all change, and with others who tend to set their hopes to new
unproven tools.

I'm often unsure where I am on the scale. I tend to think of myself
as conservative, but there are certainly things which are too
conservative for me (or I'd still stick to C like most programmers I
know). And sometimes I find myself doing work which is fun but not
strictly needed ...

/Jorgen

 

[Jorgen Grahn]

.

I don't think there's anything inherently wrong with "most classes derive
from object". Having an object superclass does have many advantages.

For those of us who have spent too much time with C++, what would
those advantages be? Based on what you write below, you seem to
describe a system where even logically unrelated classes derive from
object, but small/numerous objects may be exempted.

The problem, I think is when "most" become "all". The various advantages
that come with a superclass come at a cost, and if you do not need any of
those advantages, you should not have to pay that cost.

I have no real experience with statically typed languages with objects
except for C++, so I may be missing something.

/Jorgen

 

[Jorgen Grahn]

For those of us who have spent too much time with C++, what would

....

I got carried away and responded to a 5 weeks old posting in a rather
long thread. Sorry. I would not have followed up if I had remembered
to check the date -- it's not fair to ask the original author to revisit
the debate again.

Time to use my newsreader's 'catchup' facility, I suppose.

/Jorgen

 

[Stefan Ram]

For those of us who have spent too much time with C++, what would
those advantages be?

In C, »void *« effectively is a supertype of all pointers. So when
you want to write a function for any kind of pointer, you can use:

f( void * );

. In Java, »java.lang.Object« is a supertype of all reference types.
By this, they can enforce that every object implements »toString()«,
which make debugging easier: You can »print« any object o, by printing
the string o.toString(). When you overwrite »toString()« in your new
class, standard functions immediately start to use this. When it makes
no sense to overwrite a java.lang.Object method in a new class, that
method can usually just be ignored without harm. So one is not forced
to always implement every java.lang.Object method for every little new
class.

 

[Öö Tiib]

For those of us who have spent too much time with C++, what would
those advantages be? Based on what you write below, you seem to
describe a system where even logically unrelated classes derive from
object, but small/numerous objects may be exempted.

It means basically standardizing some common virtuals like 'equals',
'swap', 'clone', 'dump' and 'hash'. On most cases those could be made
to default to something that makes sense:
'T* T::clone() const {return new T(*this);}'

The advantages (and disadvantages) of it can be similar to other
implicitly available things. There is number of such things in C++
(like copy constructor or assignment operator) already. Sometimes these
are helpful.

RTTI is currently used for IMHO lot uglier things like 'dynamic_cast<>'
and 'typeid'. I don't know any C++ compilers that implement virtual
functions and RTTI with using something else but vtable pointer. Since
that thing is already there then few fixed entries in pointed at vtable
could be reserved for such implicit virtual functions.

Also the feature could be made optional if someone really has millions
of polymorphic classes but does not need those functions.

 

[Balog Pal]

I don't think there's anything inherently wrong with "most classes
derive from object".

I do.

Having an object superclass does have many advantages.

Like? Please list thee of the "many". Or at least one.

 

[James Kanze]

It means basically standardizing some common virtuals like 'equals',
'swap', 'clone', 'dump' and 'hash'. On most cases those could be made
to default to something that makes sense:
'T* T::clone() const {return new T(*this);}'

I'm afraid I don't see the logic here. Consider equals. In
C++, this is spelled operator==, and it is implemented over a
large number of object types (like int, double, etc.). Making
everything derive from Object, and have a virtual function
equals, however, doesn't make sense: it means that you can
compare the incomparable, and only get an error at runtime,
rather than from the compiler. Similar comments apply to all of
the functions you define: they don't make sense across unrelated
types (and in some cases, don't make sense at all).

Not to mention that most classes in (well written) C++ don't
have virtual functions.

The advantages (and disadvantages) of it can be similar to other
implicitly available things. There is number of such things in C++
(like copy constructor or assignment operator) already. Sometimes these
are helpful.

Things like copy construction and assignment were originally
only present for reasons of C compatibility.