C++... is it dying?

[puzzlecracker]

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 ?

Will new standardization create new markets for c++ developers and
applications, will it expand the application domain?



These are broad questions, seeking some reassurance, hope... well,
perhaps not so dramatic, but am genuinely curious what other think
about.


PuzzleCrakcer!

 

[george.priv]

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 ?

Will new standardization create new markets for c++ developers and
applications, will it expand the application domain?

C++ urgently needs support for multi-threading/tasking IMHO.

 

[Roland Pibinger]

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.

because the 'traditional' way of writing real-world C++ code is still
better than 'modern' C++.

How popular is this scenario?

very popular. Even Google uses it.

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

Maintainance programming isn't that bad if you value a relatively
secure job. Maintaining a large grown code base and understanding the
domain logic behind is anything but simple.

Will new standardization create new markets for c++ developers and
applications, will it expand the application domain?

Nothing from the new Standard I've seen so far supports this
speculation. Quite the contrary. The C++ Standards committee seems to
have lost any contact with real-world C++ programming. They attempt to
add even more complexity to an already over-complex language.

These are broad questions, seeking some reassurance, hope... well,
perhaps not so dramatic, but am genuinely curious what other think
about.

C++ is still strong in certain niches where it is mostly used as a
better C (C with classes). Job ads nowadays often look for C/C++
skills instead of 'pure' C or C++ skills.

 

[sasha]

C++ urgently needs support for multi-threading/tasking IMHO.

Indeed, do you think the support for multi-threading application will
again put C++ at the top of food chain, and resume its gain in
popularity?

Don't forget, a plethora of libraries that support multi-threading is
already in existance, making it a language feature would be no more
that convenience, I think.


C++ should also enter the realm of Internet. And once it does, it will
with ease displace java and other powerhouse.

how about making C++ a platform neutral?

How about making faster?

 

[puzzlecracker]

C++ urgently needs support for multi-threading/tasking IMHO.

Indeed, do you think the support for multi-threading application will
again put C++ at the top of food chain, and resume its gain in
popularity?

Don't forget, a plethora of libraries that support multi-threading is
already in existance, making it a language feature would be no more
that convenience, I think.

C++ should also enter the realm of Internet. And once it does, it will
with ease displace java and other powerhouse.

how about making C++ a platform neutral?

How about making faster?

 

[puzzlecracker]

because the 'traditional' way of writing real-world C++ code is still
better than 'modern' C++.

Why? Isn't more error-prone, harder to maintain, and becoming obsolete
given that new and improved libraries sooner, if not already, catching
up in speed and features?

Maintainance programming isn't that bad if you value a relatively
secure job. Maintaining a large grown code base and understanding the
domain logic behind is anything but simple.

Thanks, sometimes aged code is a big pile of mess...it just doesn't
get better with time, contrary to wine. Otherwise, I agree, it's
fairly challenging. I still want to move on to build systems ground
up in c++... though language is not the prerogative for that.

Nothing from the new Standard I've seen so far supports this
speculation. Quite the contrary. The C++ Standards committee seems to
have lost any contact with real-world C++ programming. They attempt to
add even more complexity to an already over-complex language.

I am under the same impression

 

[Roland Pibinger]

In the grand scheme of things, STL matured fairly
recently. Plenty of code still around, dating back from pre-STL days.

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

New development, going forward, should use STL, and modern language
features.

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

 

[izmirli]

C++ urgently needs support for multi-threading/tasking IMHO.

yes now multicore processors needs threads. and threads not standart
in C++.
But threads can efficiently be used up to 4 cores. not more cores.
That is threads
are short term solution, not long term. I think that 16/32/.. etc core
chips will be
produced soon. And a great probability, transaction memory management
as a real
solution for multicores will be used in the next time.. Tö my opinion
transaction memory management should be in C++

 

[puzzlecracker]

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

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

 

[george.priv]

Indeed, do you think the support for multi-threading application will
again put C++ at the top of food chain, and resume its gain in
popularity?

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

Don't forget, a plethora of libraries that support multi-threading is
already in existance, making it a language feature would be no more
that convenience, I think.

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.

C++ should also enter the realm of Internet. And once it does, it will
with ease displace java and other powerhouse.

That will be more realm of run-time libraries (as is with Java
or .NET).

 

[James Kanze]

On Jul 20, 12:36 pm, puzzlecracker <[email protected]> wrote:

C++ urgently needs support for multi-threading/tasking IMHO.

It has it in practice, but it certainly does need that that
support be standardized. Which will be the case when the next
version of the standard appears.

 

[george.priv]

yes now multicore processors needs threads. and threads not standart
in C++.
But threads can efficiently be used up to 4 cores. not more cores.
That is threads
are short term solution, not long term. I think that 16/32/.. etc core
chips will be
produced soon. And a great probability, transaction memory management
as a real
solution for multicores will be used in the next time.. Tö my opinion
transaction memory management should be in C++

I agree, support for MT should include protected memory access of some
sort. Challenge is to make it in elegant way that may prove impossible
without restricting use of raw pointers.

 

[James Kanze]

Fairly popular, I'd say. In the grand scheme of things, STL
matured fairly recently. Plenty of code still around, dating
back from pre-STL days.

Typically, it takes something like 25 years for practice to
catch up with theory, so don't expect STL to dominate even
today. The current situation is that you get all possible
extremes: STL, Boost and TMP taken to a point beyond reason, and
people who refuse to even consider using templates. Most shops
are somewhere near the middle of the continuum, however,
integrating the STL in their new code, and maybe even a few
parts of Boost, but avoiding the extremes.

New development, going forward, should use STL, and modern
language features.

Green fields projects, yes. New modules in existing code still
have to interface with the existing code (which can be a pain at
times, when you know that much better solutions exist).

I believe that there will be plenty of new markets for skilled
C++ developers, as less-skilled developers will migrate to
Java and .NYET,

The bluffers migrate to the "in" language. I think Java has
passed that stage by now (and I can remember when it was C++,
and some of the CV's we saw).

and when management comes to a realization that well-written,
efficient C++ code will spank the monkey out of Java and
.NYET.

I doubt that efficiency of the code will play a role. The fact
that in a well managed project, C++ will typically result in
higher programmer efficiency and more reliable code will swing
the balance, however.

 

[James Kanze]

Indeed, do you think the support for multi-threading
application will again put C++ at the top of food chain, and
resume its gain in popularity?

Don't forget, a plethora of libraries that support
multi-threading is already in existance, making it a language
feature would be no more that convenience, I think.

C++ should also enter the realm of Internet. And once it does,
it will with ease displace java and other powerhouse.

C++ is in the realm of the Internet, and it's used for a lot
more things there than Java. Server side, reliability is
usually important, for example, which means C++ (preferrably
with the Boehm collector, to avoid the security problems caused
by a lack of garbage collection), and not Java.

how about making C++ a platform neutral?

Because it isn't really appropriate. Or necessary. Most
network software is written for just a couple of machines.
That's the whole point of networking: the problem comes to you;
you don't have to go to it.

How about making faster?

Than what? C++ is, on the average, as fast as any of the other
languages out there. And pretty much all of the widespread
languages are "fast enough".

 

[James Kanze]

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

According to who? We use them on a 24 core system on our
servers. There's no real upper limit.

That is threads are short term solution, not long term. I
think that 16/32/.. etc core chips will be produced soon.

Most large scale servers have been 16 or more core for quite
some years now.

 

[Ian Collins]

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

Now? Multi-processor systems have been with us for as long as C++ has.

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

That is threads
are short term solution, not long term. I think that 16/32/.. etc core
chips will be
produced soon.

SMP machines with way more processors than that have been with us for
years. Maybe not in the windows world, but common in Unix.

And a great probability, transaction memory management

as a real
solution for multicores will be used in the next time.. Tö my opinion
transaction memory management should be in C++

Once it works....

 

[Matthias Buelow]

Job ads nowadays often look for C/C++
skills instead of 'pure' C or C++ skills.

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

 

[peter koch]

On 20 Jul., 20:46, (e-mail address removed) (Roland Pibinger) wrote:
{snip]

Nothing from the new Standard I've seen so far supports this
speculation. Quite the contrary. The C++ Standards committee seems to
have lost any contact with real-world C++ programming. They attempt to
add even more complexity to an already over-complex language.

{snip]
So what parts of the new standard are bad, and what necessary parts
were left out?

/Peter

 

[Chris Thomasson]

[...]

yes now multicore processors needs threads. and threads not standart
in C++.
But threads can efficiently be used up to 4 cores. not more cores.
That is threads

Ummm... I don't know where you get your information, but threads can
DEFINITELY scale up to very high number of processors. You need to know
how to efficiently apply various distributed algorithms to multi-threading.
For instance, I have been using a multi-threaded message-passing scheme that
I recently converted to use Kautz graph's like the SiCortex super-computer.
This thing can scale to basically any number of cores. Alls you need are
three
input and output single producer/consumer wait-free queues and a single
event-count per-thread to realize this. Best case scenario is a direct link
from message source to destination, worst cast is a _single_ hop. IMVOH,
that's
pretty damn good. I would love to see a message-passing implementation that
can beat it because I love to learn new things!

:^D

are short term solution, not long term. I think that 16/32/.. etc core
chips will be
produced soon. And a great probability, transaction memory management
as a real
solution for multicores will be used in the next time.. Tö my opinion
transaction memory management should be in C++

transaction memory has it own set of problems, one being live-lock. I would
go with message-passing... Keep in mind that there are no silver bullets
here...

 

[peter koch]

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

Is this indeed so? I just don't see how having STL not being value-
based could be possible in the first place. 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 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.

/Peter