The Future of C++ ?

[blangela]

If you had asked me 5 years ago about the future of C++, I would have
told you that its future was assured for many years to come. Recently,
I have been starting to wonder.

I have been teaching C++ at a local polytechnical school here in
Vancouver, Canada for approximately 8 years. Six years ago, at the
height (or should I say volume?) of the internet bubble, I had 80+
students per semester in my C++ course. Now I am fortunate to have 15
students per semester. What has changed? I believe that students are
no longer interested in learning C++. They would rather learn .NET
languages or Java (my colleages who teach these courses seem to be very
busy!). I believe it is because these other languages are easier to
learn and/or are perceived to be more relevant today.

I do believe that C++ is more difficult to learn than many of these
other languages. Despite my best efforts to make them exciting, I see
the eyes of my students start to glaze over when I start explaining
pointers. When I ask them to tokenize an english sentence (using the
strtok() function) and print the token in reverse order (they need to
declare an array of type char * and save the addresses of the tokens in
this array), I experience near panic from many of my students. But
these concepts need to be taught in a responsible C++ course. As was
pointed out to me recently, Microsoft still requires applicants to
demonstrate a very good knowledge of string manipulation using C-style
strings (none of these fancy string class objects!) when recruiting C++
programmers.

The ironic part is there is still a large demand for C++ developers
here in Vancouver. In fact, the company that I believe employs the
most developers here in Vancouver, employs almost entirely C++
programmers. This company, Electronic Arts (if you have not heard of
them, I guarantee that your kids have -- they create video games) is
only one of several gaming companies here in Vancouver that employ
primarily C++ programmers. Other companies like Kodak, MDSA, Nokia,
MDSI, etc. also employ large numbers of C++ programmers. Not
surprisingly, I have talked to several companies here in Vancouver who
are complaining that they are having difficulty finding C++ developers
and are looking at trying to recruit from abroad (eastern Europe
primarily).

I believe that many of these companies will be forced to migrate away
from C++ in the near future, simply because they will not be able to
find C++ programmers in the future. Soon the baby boomer C++
programmers will begin to retire, then the proverbial @@@@ will really
start to hit the fan!

Please tell me I am wrong, and paint me a view of the future which
includes C++.

[Mirek Fidler]

lock-free update if a word

------------------------

1 interlocked instruction

lock-based update of a word
-----------------------------

2 interlocked instructions
1 store

OK, as store is probably negligible, lock-free algorithm means saveing
one interlocked instruction, right?

BTW, do you have some info how really are expensive those atomic
operations?

I have seen numbers from 20 times more expensive to 1000 times more
expensive than non-atomic versions.

Is this making any sense to you? I don't think that I am a very good
teacher, but I try... So try to bear with me here...

Yes. Actually, after understanding the basic concept (that lock-free
still uses atomic operations, so it is lock-free, not LOCK-free), rest
is simple :)

Does strong safety here mean that I would be able to read and/or write
the String without locking?

Once you acquire a strong reference to you string object, you can do
lock-free COW via. CAS.

But is not it more expensive in reality for String class? Without
explicit serialization, I can lock only variables that are shared
across threads, with 'strong reference', CAS costs will be omnipotent,
right?

[Chris Thomasson]

"Mirek Fidler" <cx*@ntllib.org wrote in message
news:11******** **************@ n67g2000cwd.goo glegroups.com.. .

>lock-free update if a word
------------------------

1 interlocked instruction

>lock-based update of a word
-----------------------------

2 interlocked instructions
1 store

OK, as store is probably negligible, lock-free algorithm means saveing
one interlocked instruction, right?

for 100% uncontended case and single-word updates, yes. Keep in mind that
the overhead of the lock kind of skyrockets if it hits contention...

Also, keep this in mind, seems like you already are, but FWIW here is some
good rules to follow:

http://groups.google.com/group/comp....f5f99388172527

http://groups.google.com/group/comp....9c78f88d2b1d65
Sound good to you?

BTW, do you have some info how really are expensive those atomic
operations?

Not numbers... He is why:

http://groups.google.com/group/comp....b7e857ef440520

[...]

>Is this making any sense to you? I don't think that I am a very good
teacher, but I try... So try to bear with me here...

Yes. Actually, after understanding the basic concept (that lock-free
still uses atomic operations, so it is lock-free, not LOCK-free), rest
is simple :)

Does strong safety here mean that I would be able to read and/or write
the String without locking?

Once you acquire a strong reference to you string object, you can do
lock-free COW via. CAS.

But is not it more expensive in reality for String class? Without
explicit serialization, I can lock only variables that are shared
across threads, with 'strong reference', CAS costs will be omnipotent,
right?

Well, the cost of acquiring a strong reference is two-interlocked
instructions (uncontended), and the cost of acquiring a weak reference is a
loopless algorithm with one-interlocked op guaranteed. The cost of swapping
a global pointer with a local pointer is a loopless algorithm with
one-interlocked op guaranteed. So there are tradeoffs.

And keep in mind that if you stick to 100% COW the string algorithm that
your using need not have any synchronization of its own. The refcount
library will keep everything in order for you...

[Joe Seigh]

Mirek Fidler wrote:

>
OK, as store is probably negligible, lock-free algorithm means saveing
one interlocked instruction, right?

No.

>
BTW, do you have some info how really are expensive those atomic
operations?

I have seen numbers from 20 times more expensive to 1000 times more
expensive than non-atomic versions.

On an 866Mhz P3 for an inlined cmpxchg I get 45 nsec w/ lock prefix
and 12 nsec w/o lock prefix. That's not counting a cache line hit.
A normal load is ~3 nsec.

The main benefit from lock-free in a preemptive multi-threaded user
environment is avoiding the overhead of thread suspend/resume when
a thread blocks. 100's of nsec at least. So if lock contention
is a problem and can't be avoided, lock-free is a possible solution.

There's lock-free stuff that doesn't use interlocked instructions or
even memory barriers. I have a hazard pointer load that's only
8 nsec in this case. And some of the proxy stuff will run just
as fast if it's amortized over things like a linked list traversal.
--
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.

[Chris Thomasson]

There's lock-free stuff that doesn't use interlocked instructions or

even memory barriers. I have a hazard pointer load that's only
8 nsec in this case. And some of the proxy stuff will run just
as fast if it's amortized over things like a linked list traversal.

It has to be a very big list, IMO... If the proxy collector acquisition
logic uses a #StoreLoad, the it fu$king wrecks the pipelines and the threads
get off to a bad start... The membar fu$cks thing up real good...

If a reader thread is continually executing searches through the same shared
data-structure, if a #StoreLoad is there, it won't get any use out of its
cache...

[Tony]

"Earl Purple" <ea********@gma il.comwrote in message
news:11******** *************@8 0g2000cwy.googl egroups.com...

>
Tony wrote:

>>
What percentage of exceptions get handled anyway (that is, in a way other
than abort)?

I don't know about percentages but in applications I write, many are
handled by logging the error. The task in hand is usually aborted but
the task isn't necessarily the whole program. You can't shutdown a
server every time a task fails.

A typical example might be a broken link to a remote server. If the
remote server is down, you log the exception and then subsequently you
might be able to reconnect. Perhaps not every action you do uses that
server anyway.

I wonder if that's a good "use exceptions" scenario rather than just
returning
an error value. I'd probably do the latter. It seems that you'd be checking
for
failure every time you called the connect function and handling that
condition
as appropriate given the context unless a 3rd party library only gave you
the
exception as a way of handling the low-level-detected non-connection. Not
getting a connection seems "too expected" to be an "exception" (what ever
they are! ;) ) with specific handling required dependent on the state of the
program (for instance, does a transaction need to be aborted?).

Not all errors warrant using the C++ exception handling mechanisms.
Somewhere there's a thread about characteristics of errors that classify
them as exceptions or "something else" ("common errors"?).
Characteristics such as: detectability, recoverability, expectability etc.
were considered and discussed. I'm not sure if there was any agreement
on what constitutes an exeption at a high level of categorization. If anyone
knows of such a thread, please post a link to it.

I think it's pretty safe to say that a program will probably require more
than
one EH mechanism to get its job done and C++ exceptions are only one
potential solution for any specific scenario being considered (context
counts).

Tony

[Mirek Fidler]

The main benefit from lock-free in a preemptive multi-threaded user
environment is avoiding the overhead of thread suspend/resume when
a thread blocks. 100's of nsec at least. So if lock contention
is a problem and can't be avoided, lock-free is a possible solution.

Win32 has CRITICAL_SECTIO N variant that spin-locks defined number of
times before suspending the thread. Is not that sort of solution in
certain cases? Is spin-lock considered "lock-free" ?

Mirek

[Chris Thomasson]

"Mirek Fidler" <cx*@ntllib.org wrote in message
news:11******** **************@ 14g2000cws.goog legroups.com...

>

>The main benefit from lock-free in a preemptive multi-threaded user
environment is avoiding the overhead of thread suspend/resume when
a thread blocks. 100's of nsec at least. So if lock contention
is a problem and can't be avoided, lock-free is a possible solution.

Win32 has CRITICAL_SECTIO N variant that spin-locks defined number of
times before suspending the thread. Is not that sort of solution in
certain cases? Is spin-lock considered "lock-free" ?

No. The spinlock is spinning on lock state, not the state you intended to
work on in the first place.

[Steven T. Hatton]

Noah Roberts wrote:

>
Steven T. Hatton wrote:

>I believe you are using the term ADT the way I learned it in college,
which
is not the way it is typically used among C++ language officionatos. The
use of ADT I learned in school has to do with linked lists and binary
trees. To Stroustrup, Koening and the gang, ADT means an interface
that 'looks like' it has/is data.

Abstract Data Type. Any data type that can contain, and work with,
generic data. That is the definition used in both cases.

That is not correct. See TC++PL(SE) §2.5.4. The "concrete" stack under
discussion would be considered an instance of an ADT in the context in
which I learned the term.

--
NOUN:1. Money or property bequeathed to another by will. 2. Something handed
down from an ancestor or a predecessor or from the past: a legacy of
religious freedom. ETYMOLOGY: MidE legacie, office of a deputy, from OF,
from ML legatia, from L legare, to depute, bequeath. www.bartleby.com/61/

[Grizlyk]

Gppd morning.

blangela wrote:

Six years ago, at the
height (or should I say volume?) of the internet bubble, I had 80+
students per semester in my C++ course. Now I am fortunate to have 15
students per semester. What has changed? I believe that students are
no longer interested in learning C++. They would rather learn .NET
languages or Java (my colleages who teach these courses seem to be very
busy!). I believe it is because these other languages are easier to
learn and/or are perceived to be more relevant today.

I think the next:

In order to write object-oriented programs, we need
1. create classes for your target description
2. support "programmin g process" and later "program modifications"
(foget the english term)
3. implement of the upper classes hierarhy effective

The last point (implementation ) is quite good for C++ and in most
cases, the process is human-independent. It does not matter, in
general, the way of object code compiling - from text files with make
or from pictures from class description etc.

Of course, we need precompiled headers, incremental compiling and so on
to effective compilation, but it is not the most week point of C++ now.
And theoretically, the C++ compiler can be changed not very much in
order to get very different types of code generations.

The first point (create classes), object-oriented designe with the help
of designe-patterns and so on looks like not the C++ matter. C++ must
allow to describe the resulted classes and it can it quite good now.

But the second point (support "programmin g process") can become C++
matter now. Why? For effective using of classes, effective using of
earlyer development code anyone really need development environment. We
need:
1. to watch all classes of programs, its links, exaples and
descriptions;
2. to watch interface of any class;
3. to open any method of class to edit with greate environment support
(insted of running alogn huge listing of single file or manual file
management);
and many so on.

I really think, it is impossible to write object-oriented programs easy
without development environment.

Noone will write std object-oriented development environment for C++ :)
No development environment - no using of earlyer development code. This
is nature of oo programming.

Some things can get from smalltalk environment, some from other
existing development environment.

People can select ".NET" or "Java" for they looks more attractively for
commercial applications, environment of development is supported by
huge companies for quite short range applications or OSes. They want to
get results "here and now".

[Noah Roberts]

Steven T. Hatton wrote:

Noah Roberts wrote:

Steven T. Hatton wrote:

I believe you are using the term ADT the way I learned it in college,
which
is not the way it is typically used among C++ language officionatos. The
use of ADT I learned in school has to do with linked lists and binary
trees. To Stroustrup, Koening and the gang, ADT means an interface
that 'looks like' it has/is data.

Abstract Data Type. Any data type that can contain, and work with,
generic data. That is the definition used in both cases.

That is not correct.

If you say so...

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

hth