C++... is it dying?

[peter koch]

I don't know, but it will give it better chances for sure.




That's more of the problem: too many libraries.  Rather have one
elegant solution.  Besides how far libraries can take you.  At some
point you will need to change the language.

So why does everybody complain that there are to few standard C++
libraries? If you look at competing languages such as Java and C# you
will realise that C++ has very little library support: E.g. the Java
library is much larger.
I like the non-monopolistic approach of C++, where the standard does
not impose to much. If you want more, you get an outside source. Of
course, there is also a downside to this - one of them being the
increased effort required by programmers.

/Peter

 

[Rui Maciel]

yes now multicore processors needs threads. and threads not standart in
C++.

Really? What's wrong with pthreads?

But threads can efficiently be used up to 4 cores. not more cores.

Really? Could you please elaborate on that?


Rui Maciel

 

[khalid302]

This is a recurring and entrenched permeating this group... hence
treat it as such

I have recently started a new job, and to my surprise, we still write
a fairly traditional c++ code, still using raw pointers, and still in
market with our products.

How popular is this scenario?

What's the future for C++, other than ceasing years of
maintainance ?

I think there are quite a number of 'mainstream' and 'modern' projects
that already use C++, for example:

* Facebook has C++ backend libraries
* MySQL is written C++
* Most Mozilla stuff is written in C++, including Firefox, to my
knowledge.

Having modern projects use C++ probably means its future will not
'ceasing years of maintenance'.

I'd assume the case seems like 'ceasing years of maintenance' with
you, because the code you are maintaining uses 'traditional' C++.

 

[khalid302]

STL was introduced in 1995 and standardized in 1998. It came from a
single source and was usable from the beginning (although popular
compilers didn't support all STL features). Moreover, STL was
tremendously hyped for years (this is not an exaggeration as anyone
interested in C++ in the late nineties can confirm). STL's low rate of
adoption is rooted primarily in the STL, not in lazy and unwilling
programmers.
The major STL problems are obvoius by now:
- restricion to value semantics
- template obfuscation, esp. through allocators
- non-optimal iterator design


I would have subscribed to this recommendation in 1998. In 2008 it is
refuted by reality.

Let's not forget that STL is implemented on top of C++'s language
features. One can implement his own replacement for STL. This is
probably one source of C++'s power.

 

[Juha Nieminen]

The only practical use of STL to this day is to code solutions in
programming challangies (TopCoder, ACM, etc).

Does that mean eg. you don't use STL for real application code? Are
you saying the STL is useless in practice?

If the answer is affirmative, I really don't get it. I use STL *a lot*
when I code as a hobby and as my payjob. It has saved me countless hours
of development and debugging time because most of the time I don't have
to implement my own data containers nor algorithms, nor do I have to
thoroughly test them for bugs.

If I had to code in C, which has no data containers nor algorithms
whatsoever (besides the horrible qsort), that would be a real nightmare.

 

[george.priv]

So why does everybody complain that there are to few standard C++
libraries? If you look at competing languages such as Java and C# you
will realise that C++ has very little library support: E.g. the Java
library is much larger.

You misunderstood, my comment. I meant libraries for MT support,
otherwise STL has plenty of basic functions to work with.

 

[Chris Thomasson]

All I have to go on is my own personal experience. When I got my first
programming job back in '98, I was genuinely concerned that my sketchy
knowledge of the STL was going to make things difficult for me. As it
turned out, my knowledge of the STL was already much greater than
anybody else in the company!
:^D




I found myself routinely having to
demonstrate how the standard containers were more efficient than any
home-grown solution any of the "old guard" could come up with.

Depending on certain conditions and requirements, I find that some
home-grown "intrusive" containers could be more efficient than the STL. No
need to allocate a node under the hood to insert an object because said
object already contains all the necessary information required to link it
into a container. Of course, this is a fairly contrived scenario indeed!

Also, it has its limitations... Inserting an object into more than one
intrusive container can be fairly tedious. However, if you know in advance
than an object will only ever be in N or less containers at any one time
throughout its lifetime, well, IMVHO, intrusive containers can indeed be
more "efficient" than the STL as it tends to eliminate the need to call
into an allocator every time an object is added/removed to/from a container.

;^)

[...]

 

[puzzlecracker]

Does that mean eg. you don't use STL for real application code? Are
you saying the STL is useless in practice?

If the answer is affirmative, I really don't get it. I use STL *a lot*
when I code as a hobby and as my payjob. It has saved me countless hours
of development and debugging time because most of the time I don't have
to implement my own data containers nor algorithms, nor do I have to
thoroughly test them for bugs.

If I had to code in C, which has no data containers nor algorithms
whatsoever (besides the horrible qsort), that would be a real nightmare.

I don't mean to downplay the the usefulness of STL, by no means. We do
use it in our company. However, a lot of times we develop data
structures bases off STL, and use our own utilities where speed is the
factor, despite the certain guarantees it makes.

I personally love STL and use it for fun...

Again, by no means I have anything against STL... (maybe gtk )

 

[puzzlecracker]

Now, I hear that

boost's lambda library is going to become part of the standard but
frankly I doubt I will ever learn it (or any of the other new parts of
the standard) as well as I know the STL.

Why not, just curious?


I have very scantly touched Boost as well as other new libraries that
have a chance of becoming a
part of the new standard though I do want find some time for that...

 

[Chris Thomasson]

Like I said, where I work the STL is considered advanced practice, I
already know stuff about the language I can't use because then no one
else will be able to work with my code. Why should I learn even more?


Oh I want to as well, and I probably will in hobby code, but that is a
very small percentage of the code I write every day.

BTW, to answer the question posed in the subject... Yes, of course C++
is dying. Everything dies.

Humm... One small nit-pick. C++ is currently living and in fairly good
health; IMHO of course. Well, I suppose the following statement makes
perfect sense:


"The human who is currently in 100% perfect health, is of course currently
dying because everything dies."


Does that sound just a little bit strange?

;^)

 

[James Kanze]

[...]

Nonsense. You would do the same thing every programming house
did before the STL came along, develop your own set of
containers and algorithms and use them. Then when someone
asked why you don't switch from what you know to this "new
improved" library, you would look at all the code you already
have written, all the evidence that your containers work and
work well, and ask "why bother?"

To which you answer: because it's standard. I've used many
different pre-standard libraries, most of them better designed
than the STL (but some real desasters in design, too). But none
of them as well known as the STL: I'm concerned with my code
being easily understood not only by the veterans who've worked
at the company for years, but by the new kids we hire next week.
For most purposes, the my GB_ArrayOf, OSE's OTC_Vector and the
standard's std::vector will work equally well, but the new hire
will already know std::vector, but not GB_ArrayOf or OTC_Vector.
(Not to mention that a lot of places where I've worked bought in
libraries like the Booch toolkit, which are no longer
supported.)

A lot of C++ engines, frameworks and libraries were developed
long before STL burst on the scene and they solved all the
problems STL solves. Why should they dump all that hard work,
that works?

So that they can interface with other engines, frameworks and
libraries. And so that there is one less thing for new hires to
learn.

Programming languages have a nasty habit of starting life
clean and well designed but with a few quirks and lacking in
some way, then they grow to become bloated beasts that have
way more than they need and even more quirks because of the
requirement that they are backwards compatible. Eventually
they die under their own weight. Either that, or the language
stagnates and eventually becomes minor niche.

C++ seems to be in the unenviable position of officially
bloating while practically stagnating.

I don't follow you here. Java came along, and pretended to
replace C++, and now it's more or less relegated to a few (very
big) niches, where as C++ continues to be widely used in a large
number of domains. Ditto a few other languages. C++ has a
number of flaws, but it is flexible, and can be adapted to meet
just about any requirements.

It is complex. For two reasons: the first is that it is used to
solve complex problems: if the complexity wasn't in the
language, it would have to be in your user code. The second is
that it derives from C, and there are a number of things in C
which are poorly designed and don't scale (e.g. the declaration
syntax). But without this relationship to C, it's probable that
the language would have followed the tracks of Modula-3: an
excellent language that just never caught on.

 

[James Kanze]

On 20 Jul., 21:29, (e-mail address removed) (Roland Pibinger) wrote:

Is this indeed so? I just don't see how having STL not being
value-based could be possible in the first place.

The STL is value-based because C++ is value-based. It would be
trivial to design the library otherwise, but such designs don't
"fit in" with the rest of the language. Many early libraries,
back before there were templates, did have containers of
Object*, and require everything in the containers to derive from
Object. It didn't work, and even back then, it was found
preferrable to use <generic.h>, with all its horrors, than to go
the route of reference semantics. There are (or have been) many
libraries better designed than STL, but they've all used value
semantics as well.

Secondly, I do not see the real obfuscation. How often do you
need to use e.g. std::vector with anything but the standard
allocator?

I agree that the best thing to do with the allocator argument is
to forget it. I does come into play if you try to use some of
the more advanced features of C++, however, like template
template parameters.

With regards to the third point, the iterator design of the STL
is a desaster, but most of the time, you can make it work
anyway.

I have never used a standard container with a non-standard
container, and every C++ project I've been developing has
taken advantage of the standard containers - to great benefit
IMO.

Having something standard is always a benefit. Often enough of
one to outweigh certain technical disadvantages.

 

[James Kanze]

Really? What's wrong with pthreads?

They don't work under Windows.

 

[James Kanze]

That's because the types who write these adverts are too
ignorant to know the difference.

Sometimes. Sometimes it's because some maintenance programming
is required.

Most of the time, though, the job offer specifies clearly C++,
and doesn't mention C.

I'd say that C++/Java or C++/C# is more in demand than C++/C.
It's not rare to have light-weight clients written in C#, or for
the front end of the web server to make use of Java Beans, while
all of the real work is done in C++. IMHO, it's a good model
(although I'd use Java for the clients as well, rather than C#).
You get the advantage of a good, standard GUI library for the
client code, and the infrastructure of your Web server to
support the development of the beans, but the programmer
productivity and the program robustness of C++ where it counts,
where the critical work is being done.

 

[James Kanze]

puzzlecracker <[email protected]> wrote:

BTW, to answer the question posed in the subject... Yes, of
course C++ is dying. Everything dies.

That's true for organic beings, but I don't know about computer
languages. Both Fortran and Cobol are alive and thriving.

Part of the question could also be: what does it mean for a
language to die? Is it just the name---would C++ die if we
decided to rename it SomethingElse? Or is it the language
itself: but the language I learned twenty years ago under the
name C++ doesn't exist anymore (no <generic.h>, for example).

One thing is certain, a language that doesn't evolve and change
will find its user community shrinking rapidly. If Fortran and
Cobol (and C++) are alive and thriving, it's because the
language today would be largely unrecognizable to someone who
learned it back when it was first conceived. (Which leads to an
interesting correlary: any language which continues to thrive
for more than twenty years will end up overly complicated. It's
the price you pay for longevity.)

 

[Chris Thomasson]

They don't work under Windows.

Well, not "officially":

http://sourceware.org/pthreads-win32


Humm, I guess they do, but not by default!:

http://technet.microsoft.com/en-us/interopmigration/bb380242.aspx


;^D

 

[Nick Keighley]

Subject: "C++...is it dying"


*what* is "recurring [,] entrenched [and] permeating this group"?
The idea that C++ is dying?


wow. Linux is still in the market and *that's* written in C!!!!


what does "ceasing years of maintainance" mean? Increasing?
Unceasing? Is it really bad to maintain a softwatr product?
Doesn't it mean your customer base is still interested in your
product?

I think there are quite a number of 'mainstream' and 'modern' projects
that already use C++, for example:

* Facebook has C++ backend libraries
* MySQL is written C++
* Most Mozilla stuff is written in C++, including Firefox, to my
knowledge.

Having modern projects use C++ probably means its future will not
'ceasing years of maintenance'.

what? Do you mean using C++ means you won't have bugs in your product?
Or no one will use your product (no maintenance implies (to me)
no customers)? Or do you *you* won't be stuck on maintenance if you
write new projects in C++?

I'd assume the case seems like 'ceasing years of maintenance' with
you, because the code you are maintaining uses 'traditional' C++.

you'll have to explain that to me

I think you have a negative attitude to products with long life
cycles. Imagine all those Oracle programmers "oh no! we've got
to work on that old DBMS system"

 

[Mirco Wahab]

What's the future for C++, other than ceasing

Viewed from another angle, there's something more:

http://www.alenz.org/mirror/khason/why-microsoft-can-blow-off-with-c.html
(*)

where the prevailing languages can be deduced
clearly from the length of their creators beards.

So far so good. But than, I found this shocking piece of evidence
http://static.flickr.com/26/62849631_1abece0b72.jpg

which almost coincides (2005) with this publication:
http://news.cnet.com/C-creator-upbeat-on-its-future/2100-1007_3-5681078.html

There's also an 2007-shot from KSU ACM meeting on wikimedia:
http://upload.wikimedia.org/wikipedia/en/5/5e/Stroustrup_kent_state.jpg

Still no beard.

What now? We'll see & hope the best ...


Regards

M.



(*) after this article appeared, at least two "beardless creators"
startet growing beards, Lerdorf (PHP, http://lerdorf.com/pics/medium/rl5.jpg)
and Matsumoto (Ruby, http://www.rubyist.net/~matz/images/matz-beard.jpg)

 

[Juha Nieminen]

Nonsense. You would do the same thing every programming house did before
the STL came along, develop your own set of containers and algorithms
and use them.

In other words, spend countless of hours developing and debugging data
containers and algorithms (and often not even catching all bugs until
during the years), for no good reason. Hours which could be used more
productively.

Then when someone asked why you don't switch from what you
know to this "new improved" library, you would look at all the code you
already have written, all the evidence that your containers work and
work well, and ask "why bother?"

If someone is starting a new project from scratch, why should he not
use what the STL has to offer? There's no "switch" to anything.

A lot of C++ engines, frameworks and libraries were developed long
before STL burst on the scene and they solved all the problems STL
solves. Why should they dump all that hard work, that works?

Why shouldn't a new C++ engine, framework or library use the STL?

 

[Roland Pibinger]

I just don't see how having STL not being value-
based could be possible in the first place.

Just take a look at the libraries from Rogue Wave or Qt.

Secondly, I do not see the
real obfuscation. How often do you need to use e.g. std::vector with
anything but the standard allocator?

The STL allocators literally multiply the length of compiler error
messages. Moreover, you don't need user-defined allocators when the
library merely uses value semantics (values and copies of values).
Even if there were a need for allocators they wouldn't have to be
template parameters.