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!

[Sam]

puzzlecracker writes:

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?

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.

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

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

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

I believe that there will be plenty of new markets for skilled C++
developers, as less-skilled developers will migrate to Java and .NYET, and
when management comes to a realization that well-written, efficient C++ code
will spank the monkey out of Java and .NYET.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAki DcbgACgkQx9p3GY HlUOI1bQCdG+b/vmKq7DKcsvQy3/Z5ej88
bWwAn0osvv5Jnnc mEVcoSsxtUfNX4l PL
=pSOG
-----END PGP SIGNATURE-----

[george.priv]

On Jul 20, 12:36 pm, puzzlecracker <ironsel2...@gm ail.comwrote:

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.

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

PuzzleCrakcer!

[Roland Pibinger]

On Sun, 20 Jul 2008 09:36:27 -0700 (PDT), puzzlecracker wrote:

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

--
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch

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

On Sun, 20 Jul 2008 12:11:21 -0500, Sam <sam@...comwrot e:

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

--
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch

[izmirli]

On Jul 20, 9:01 pm, george.p...@gma il.com wrote:

On Jul 20, 12:36 pm, puzzlecracker <ironsel2...@gm ail.comwrote:

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.

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

PuzzleCrakcer!

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