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++.
Nov 18 '06
190  7892 
"Alf P. Steinbach" <al***@start.nowrote in message
news:4t************@mid.individual.net...
>Exceptions just solve the problem of how to handle errors in those
functions.
No, that problem is not a problem that can be solved by other known means.
So how do you handle a constructor error without exceptions?
>Constructors weren't created as a result of exception handling, EH was
created as a result of constructors.
No, that's incorrect. Exceptions were adopted late in the standardization
process, that's true. But first, they weren't invented to support
constructors, nor vice versa, and second, they weren't invented in C++.
Experience with exceptions had been gained from Ada and other languages,
as well as at a low level in e.g. Windows NT. They fitted the
requirements of constructors, and no other scheme did.
I meant the reason why they were implemented in C++ (context counts).
Tony
"Kai-Uwe Bux" <jk********@gmx.netwrote in message
news:ek**********@murdoch.acc.Virginia.EDU...
A C++ course is neither a substitute for an
introduction to computer architecture nor a class on data structures and
algorithms.
The topics need not be taught separately though. It's up to the course
designer to decide what the scope will be. It could be a lot of C++ with
data structure examples sprinkled in (may as well learn something useful
while learning syntax) or it could be a lot of design with a little C++
as the implementation language. The latter being similar to books on
OO that give C++ examples but don't implement production-level code
because they are more concerned with the patterns than the language
idiosyncracies.
Tony
"Chris Thomasson" <cr*****@comcast.netwrote in message
news:-N******************************@comcast.com...
>Student: I hear the C++ Standard has a nice vector template?
Teacher: Well, yes it does. And you will learn exactly how to create a
Standard C++ vector template from scratch. This class will teach you how
to implement useful parts of the C++ Standard. The class uses the
namespace myclass_std for the minimalist Standard C++ template library
you will be creating.
Sound good to me, no?
That might be a good name for a book...
"Implementing Standard C++"
"Accelerated C++" is a book that already works the vector problem above.
Tony
Frederick Gotham wrote:
Walter Bright:
>Frederick Gotham wrote:
>>For instance, let's say I'm driving fast, but there's a bend up ahead.
I want to get through that bend as quickly as possible. Driving an
automatic, I'll break as I approach the bend, then turn, then
accelerate once I'm through the turn. Driving a manual, I'll drop a
gear as I approach the bend, then the car will slow as I re-engage the
engine dragging the revs up, then I'll turn, then when I'm through the
turn, I'll slip the clutch and acclerate. The automatic method is
certainly simpler, but the manual method is far more efficient.
Using the engine to slow down the car is not efficient.
Not efficient in terms of what? Racing performance or car maintenance?
Not efficient in terms of fuel usage, performance, dollars, or maintenance.
It
slows the car down at an appropriate rate without using any energy. The
breaks, on the other hand, use energy.
The brakes don't use energy, they disperse it.
>It puts excessive wear on the engine as unburned fuel in the cylinders
will wash the oil off the cylinder walls, causing more wear. It wastes
fuel.
Actually, I think most cars cut off the petrol supply when they sense that:
(1) The accelerator isn't depressed.
(2) The revs are falling below minimum.
Maybe some do. Most do not. Certainly, carbureted ones do not.
I've never heard of "cluth-engage braking" wearing the engine, no more so
than simply reving the engine.
Now you have <g>.
>Use the brakes. That's what the darned things are for! They're a lot
cheaper to replace than the engine is.
Actually, people who have driven both manual and automatic argue the exact
opposite:
Breaks wear quicker in an automatic, and they're more expensive
to replace than a clutch. My own father drove an automatic for about a
decade, then a manual for about five years, and now he's back in an
automatic. He says that he spent much more money on maintenance for the
automatics, particularly the brakes.
Brake pads are $25 each, and you need 4. You can't touch a clutch job
for that. How you drive can also have a big impact on brake wear and
clutch wear. I usually get twice the life out of a clutch that "normal"
people do.
>Proper maximum performance turning technique is:
1) Brake as late as possible, and as hard as possible (just up to
locking, but not actually locking, the tires), just before turning the
wheel.
If the objective is to slow down _as_ _fast_ _as_ _possible_,
No, the objective is to get around the track as fast as possible.
Braking later and harder means your average speed is higher.
then yes.
This method is a little extreme though if you're driving through a
neighourhood.
Generally, you shouldn't be using maximum performance driving techniques
where kids are playing in the street.
>1.5) While braking, heel-toe double clutch to insert the transmission
into the right gear for the turn exit. Engage the clutch *before*
finishing braking, which also means 'feeling' the engine revs to match
up with the transmission speed so there is no slipping.
If I'm not mistaken, not even competitive drivers double-clutch anymore,
ever since the advent of synchromeshes in the gear box.
A lot of racing trannies do not have synchros, as they are not needed
for competent drivers, and they are more complex and prone to failure.
I belive the "drop
a gear and engage the clutch dragging up the revs" braking method is
superior, as the revs are just at the right rate when you want to
accelerate out of the turn. If you need more stopping power, then you can
always push the brake at the same time.
You can believe whatever you want. But my information comes from:
1) mechanics who work on professional race cars
2) professional race car drivers
3) (1) and (2) who took the time to explain the physics of it to me
4) I have an undergraduate degree in mechanical engineering
5) I have taken cars completely apart and reassembled them, so I am very
familiar with how they work.
Your belief is a common one, but it is simply wrong. For one thing, the
engine does not add to the "stopping power". The stopping power is
limited by the grip of the tires on the pavement. The brakes can
*easily* exceed this. Using the engine in addition to the brakes causes
problems because the engine braking only happens on the rear wheels.
Brake pressures are very carefully 'biased' front to rear, throwing in
engine braking just on the rear will upset that, most likely causing the
back end to slide out from under you.
>3) Keep constant pressure on the gas, adding or releasing pressure will
cause a slide.
Not too sure on this one. I did a race course there a little while ago, and
all I did was brake in a straight line, then release the brake and turn the
wheel. When through the apex of the turn, I hit the accelerator hard. (I
didn't hold on the accelerator going through the turn.)
The problem is called "lift throttle oversteer", and I've done it. You
get a nice spin doing it.
>4) After the apex, gradually straighten the wheel applying pressure to
the gas, again in a coordinated manner to keep constant pressure on the
wheels at just short of skidding.
I take it you don't do drifting :)
Drifting is something entirely different, and it is not about maximum
speed through a turn. Drifting is more of an art form. Drift cars are
deliberately set up to minimize weight on the back tires so they'll
slide easily.
In normal driving, the main advantages of "clutch-engage-drag-up-revs
braking" is that the brakes don't get worn, and that you're at a nice rev-
rate when you're exiting the turn.
In race driving, use of this braking method will help keep the brakes cool,
Brake overheating can be a problem with race cars, but this problem has
been solved by building better heat dispersing brakes.
plus you'll be at a nice rev-rate when leaving the turn.
Um, you put the car in the right gear to get the right rpms on turn
exit. That has nothing to do with using the engine to slow the car down.
That said though, double-clutching is good fun. I used to do it... until I
needed a new clutch.
Double clutching properly actually reduces the wear on the clutch (and
transmission).
I tried heal-toe braking one time but I nearly caused
an "accident".
Few can do it properly, and it takes a lot of practice. You shouldn't
practice it in traffic.
I don't know the exact physics behind it, but I find that intentionally
slipping the clutch upon exiting a turn gives that extra little bit of
acceleration (might be something to do with torque but I don't know).
Probably because your engine doesn't pull well at low revs, and slipping
the clutch gives you more revs. That's hard on the clutch, though, and
you might consider dropping a gear.
In article <66******************************@comcast.com>,
Walter Bright <wa****@digitalmars-nospamm.comwrote:
Frederick Gotham wrote:
Walter Bright:
Frederick Gotham wrote:
For instance, let's say I'm driving fast, but there's a bend up ahead.
I want to get through that bend as quickly as possible. Driving an
automatic, I'll break as I approach the bend, then turn, then
accelerate once I'm through the turn. Driving a manual, I'll drop a
gear as I approach the bend, then the car will slow as I re-engage the
engine dragging the revs up, then I'll turn, then when I'm through the
turn, I'll slip the clutch and acclerate. The automatic method is
certainly simpler, but the manual method is far more efficient.
Using the engine to slow down the car is not efficient.
Not efficient in terms of what? Racing performance or car maintenance?
Not efficient in terms of fuel usage, performance, dollars, or maintenance.
It
slows the car down at an appropriate rate without using any energy. The
breaks, on the other hand, use energy.
The brakes don't use energy, they disperse it.
<snip>
Ok, I have to put this into perspective.
I just got through reading a post here complaining that discussing
hash_map was off topic for comp.lang.c++ because it isn't in the
standard. Such a statement isn't what I would personally call rational,
but hey, everyone is entitled to their opinion. And it happens daily
here at comp.lang.c++. Over the years I've come to actually enjoy
reading such posts in a somewhat warped and twisted way. I've become
amused at what the next self-appointed moderator will claim as off
topic. Ok it's cheap entertainment, but better than reality TV.
Then I see this "future of C++" thread. Gee, that thread has been going
on forever. What could they possibly be discussing over there?!
Cars.
Not software in cars. Just driving techniques. :-)
This isn't a flame on Walter. Walter is a great guy who I've personally
met (Hi Walter!). I'm just chuckling at the irony, and being off topic
myself. :-)
-Howard
* Tony:
"Alf P. Steinbach" <al***@start.nowrote in message
news:4t************@mid.individual.net...
>>Exceptions just solve the problem of how to handle errors in those
functions.
No, that problem is not a problem that can be solved by other known means.
So how do you handle a constructor error without exceptions?
You don't: you transform it to something else.
E.g., you can transform it to a fatal error (aborting the program), or
to a silent failure (ignoring further operations), or to a recurring
nightmare (e.g. popping up an error dialog box for every attempted
operation on the object), or most likely, you'll either transform it to
an initialization failure by using two-phase construction, where the
constructor no longer has a role to play, or, which may arise naturally
with two-phase construction, to a nest of bugs.
No matter which such course is taken the problem persists.
>>Constructors weren't created as a result of exception handling, EH was
created as a result of constructors.
No, that's incorrect. Exceptions were adopted late in the standardization
process, that's true. But first, they weren't invented to support
constructors, nor vice versa, and second, they weren't invented in C++.
Experience with exceptions had been gained from Ada and other languages,
as well as at a low level in e.g. Windows NT. They fitted the
requirements of constructors, and no other scheme did.
I meant the reason why they were implemented in C++ (context counts).
There were many reasons. In his paper "What is "Object-Oriented
Programming?"", mid 1986, Bjarne Stroustrup wrote
As programs grow, and especially when libraries are used extensively,
standards for handling errors (or more generally: "exceptional
circumstances") become important. Ada, Algol68, and Clu each support a
standard way of handling exceptions. Unfortunately, C++ does not.
Where needed exceptions are "faked" using pointers to functions,
"exception objects," "error states", and the C library signal and
longjmp facilities. This is not satisfactory in general and fails even
to provide a standard framework for error handling.
I pulled that quote from <url:
http://www.research.att.com/~bs/hopl2.pdf>, where he further writes that
"Exceptions were considered in the original design of C++, but were
postponed because there wasn't time to do a thorough job of exploring
the design and implementation issues. Exceptions were considered
essential for error handling in programs composed out of separately
designed libraries. The actual design of the C++ exception mechanism
stretched from 1984 to 1989."
Now go do your own research... ;-)
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Frederick Gotham wrote:
Steven T. Hatton:
>What happens when somebody just happens to define something in a library
you include in your code that breaks your macros? It happens.
What happens when someone hits their finger with a hammer? Do we stop
selling hammers?
If someone else hits my thumb with a hammer, that becomes a different story.
If I get hit by the head of a hammer because it fell off the handle, I'm
going to look into why that happened. If it happens repeatedly with the
same make of hammer, I'm going to go looking for a new kind of hammer.
>Among
those changes was to remove certain header files which appeared to be
superfluous, and were not indicated in the documentation as essential to
the feature I was trying to implement.
So why did you have these header files included in the first place?
Because it was part of the sample code, and it is an "include everything"
file the library provider has taken to using in their implementation files.
It may be due to a suggestions in the Template book by van de Voorde and
Josuttis. Something I am now convinced was bad advice. I took it out
because I only want what is necessary to make my code work. That avoids
introducing hidden dependencies such as the one I discovered.
> Among
those elements was a header file which *should* *not* have made a
difference. Nonetheless, it *did* make a difference.
It didn't by any chance have:
#undef MY_SPECIAL_MACRO
The fix was not taking it out. It was putting it in. I really don't know
what it had in it. Ironically, I had opted for not going with the
bleedingest edge stuff for a change - reasoning that such problems would be
less likely. Well, they seem to have corrected it in the development
branch. They now have header files with sane names that work.
>
>What is even more bizarre is that at one point, explicitly adding a
default constructor signature to a pure abstract base class caused the
damn thing to work!
Sounds a little odd, I'd have to look at the code to see what's happening.
I wouldn't try to reproduce the problem if my life depended on it at this
point.
>I believe there is a place for "cookie cutter" code. What Cpp provides
is a means of crossing the boundary between code text, and compiled
code.
And it's very handy, as shown by my IN_TERMS_OF macros.
I like to see code written out in C++. I can understand that. Even if I
don't see everything relevant to the situation, I can usually get a pretty
good idea of what the possibilities are directly from the immediate code.
That simply doesn't work with Cpp.
>It is a form of recursive self-reference, if you will pardon the
redundancy. That is actually a very powerful ability. Unfortunately
it's provided by a very weak tool.
The preprocessor is just fine as far as I'm concerned. I just hope we get
Variable Length Argument List macros also.
You probably also think vi should be used for more than fixing an emacs
build script in a pinch.
You should see some of the works of genius they churn out over on
comp.lang.c. Ever heard of IMAX_BITS?
I've attempted to read the GCC code. Some people might find it wonderful.
I found it painful. I can read Roberto's parser. I even wrote an XML tree
walker over it that dumped the AST to XML tags. I can't imagine there is
something significantly faster.
>
>When I see macros, I consider the time I have spent trying to fix Cpp
related problems, and they never seem to have the potential for saving
that much time.
I think they're great, C++ would be less of a language without them.
I _know_ they make creating versatile and powerful development tools more
difficult. I also know that they cause a lot of problems for me and for
other people. It's often not even the number of problems they create that
incurs the real cost. It's the difficulty in identifying and solving the
problems they create. The make the language significantly harder to learn,
and they make it less pleasant to work with. Much of what is done with
macros can be done with templates, or native code. What I enjoy doing with
C++ is finding the one-liner that is both expressive to the human reader,
and ideal for solving a problem for which someone - perhaps me - has
written several lines of code.
If often take a fair amount of thinking and investigating what the
capabilities of the available constructs are. But I have found that I can
often reduce the size of a program significantly, while at the same time
make it more maintainable and flexible.
--
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/
"Alf P. Steinbach" <al***@start.nowrote in message
news:45**************@start.no...
>* Tony:
>"Alf P. Steinbach" <al***@start.nowrote in message
news:4t************@mid.individual.net...
>>>Exceptions just solve the problem of how to handle errors in those
functions.
No, that problem is not a problem that can be solved by other known
means.
So how do you handle a constructor error without exceptions?
You don't: you transform it to something else.
E.g., you can transform it to a fatal error (aborting the program), or to
a silent failure (ignoring further operations), or to a recurring
nightmare (e.g. popping up an error dialog box for every attempted
operation on the object), or most likely, you'll either transform it to an
initialization failure by using two-phase construction, where the
constructor no longer has a role to play, or, which may arise naturally
with two-phase construction, to a nest of bugs.
No matter which such course is taken the problem persists.
What percentage of exceptions get handled anyway (that is, in a way
other than abort)?
>
>>>Constructors weren't created as a result of exception handling, EH was
created as a result of constructors.
No, that's incorrect. Exceptions were adopted late in the
standardization process, that's true. But first, they weren't invented
to support constructors, nor vice versa, and second, they weren't
invented in C++. Experience with exceptions had been gained from Ada and
other languages, as well as at a low level in e.g. Windows NT. They
fitted the requirements of constructors, and no other scheme did.
I meant the reason why they were implemented in C++ (context counts).
There were many reasons. In his paper "What is "Object-Oriented
Programming?"", mid 1986, Bjarne Stroustrup wrote
[...]
Well why they were deemed most necessary then rather than all the
potential benefits.
Tony
* Tony:
"Alf P. Steinbach" <al***@start.nowrote in message
news:45**************@start.no...
>* Tony:
>>"Alf P. Steinbach" <al***@start.nowrote in message
news:4t************@mid.individual.net...
Exceptions just solve the problem of how to handle errors in those
functions.
No, that problem is not a problem that can be solved by other known
means.
So how do you handle a constructor error without exceptions?
You don't: you transform it to something else.
E.g., you can transform it to a fatal error (aborting the program), or to
a silent failure (ignoring further operations), or to a recurring
nightmare (e.g. popping up an error dialog box for every attempted
operation on the object), or most likely, you'll either transform it to an
initialization failure by using two-phase construction, where the
constructor no longer has a role to play, or, which may arise naturally
with two-phase construction, to a nest of bugs.
No matter which such course is taken the problem persists.
What percentage of exceptions get handled anyway (that is, in a way
other than abort)?
Try to do your own research.
>>>>Constructors weren't created as a result of exception handling, EH was
created as a result of constructors.
No, that's incorrect. Exceptions were adopted late in the
standardization process, that's true. But first, they weren't invented
to support constructors, nor vice versa, and second, they weren't
invented in C++. Experience with exceptions had been gained from Ada and
other languages, as well as at a low level in e.g. Windows NT. They
fitted the requirements of constructors, and no other scheme did.
I meant the reason why they were implemented in C++ (context counts).
There were many reasons. In his paper "What is "Object-Oriented
Programming?"", mid 1986, Bjarne Stroustrup wrote
[...]
Well why they were deemed most necessary then rather than all the
potential benefits.
Try to do your own research. I can suggest the D&E book. But I haven't
read it.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
"Alf P. Steinbach" <al***@start.nowrote in message
news:4t*************@mid.individual.net...
>* Tony:
>"Alf P. Steinbach" <al***@start.nowrote in message
news:45**************@start.no...
>>* Tony:
"Alf P. Steinbach" <al***@start.nowrote in message
news:4t************@mid.individual.net...
>Exceptions just solve the problem of how to handle errors in those
>functions.
No, that problem is not a problem that can be solved by other known
means.
So how do you handle a constructor error without exceptions?
You don't: you transform it to something else.
E.g., you can transform it to a fatal error (aborting the program), or
to a silent failure (ignoring further operations), or to a recurring
nightmare (e.g. popping up an error dialog box for every attempted
operation on the object), or most likely, you'll either transform it to
an initialization failure by using two-phase construction, where the
constructor no longer has a role to play, or, which may arise naturally
with two-phase construction, to a nest of bugs.
No matter which such course is taken the problem persists.
What percentage of exceptions get handled anyway (that is, in a way
other than abort)?
Try to do your own research.
The question was rhetorical.
>
>>>>>Constructors weren't created as a result of exception handling, EH
>was
>created as a result of constructors.
No, that's incorrect. Exceptions were adopted late in the
standardization process, that's true. But first, they weren't
invented to support constructors, nor vice versa, and second, they
weren't invented in C++. Experience with exceptions had been gained
from Ada and other languages, as well as at a low level in e.g.
Windows NT. They fitted the requirements of constructors, and no
other scheme did.
I meant the reason why they were implemented in C++ (context counts).
There were many reasons. In his paper "What is "Object-Oriented
Programming?"", mid 1986, Bjarne Stroustrup wrote
[...]
Well why they were deemed most necessary then rather than all the
potential benefits.
Try to do your own research. I can suggest the D&E book. But I haven't
read it.
That wasn't a question (note the absence of any question mark).
Tony
* Tony:
>
The question was rhetorical.
That wasn't a question (note the absence of any question mark).
Conceptual PLONK.
That means, I'll not be responding to your articles except perhaps to
resque others from misunderstandings.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Howard Hinnant wrote:
Ok, I have to put this into perspective.
I just got through reading a post here complaining that discussing
hash_map was off topic for comp.lang.c++ because it isn't in the
standard.
I think if you go back and reread what was said you'll find that nobody
said what you are saying was said.
"Kai-Uwe Bux" <jk********@gmx.netwrote in message
news:ek**********@murdoch.acc.Virginia.EDU...
Chris Thomasson wrote:
>"Earl Purple" <ea********@gmail.comwrote in message
[snip]
>>Course in Java: [...]
>>And we can process concurrently...
C++ is very useful because
I can use it with Assembly Language to create a high-end synchronization
algorithms. I can use to create a full blown Java VM... I can use C++ to
prototype virtually anything for that matter. Can't use Java for any of
that.
I would like to see the C++ course completion of which will enable you to
create a full blown Java VM. Do you seriously suggest that, say, as a term
paper?
I think I could put together a couple of courses that would teach a student
how to make use of lock-free data-structures' in the context of a virtual
machine. The course would have a prerequisite for basic SPARC or IA-32
Assembly Language skills and fairly advanced knowledge in data-structures
and C or C++; I suggest a course that teaches how to implement the Standard
C++ template library. The virtual machine would of course have a weak cache
coherency, and a very clear memory model... I could go on and on, but it off
topic.
;^)
"Alf P. Steinbach" <al***@start.nowrote in message
news:4t*************@mid.individual.net...
>* Tony:
>>
The question was rhetorical.
That wasn't a question (note the absence of any question mark).
Conceptual PLONK.
That means, I'll not be responding to your articles
Thanks.
Tony
Alf P. Steinbach wrote:
I pulled that quote from <url:
http://www.research.att.com/~bs/hopl2.pdf>, where he further writes that
"Exceptions were considered in the original design of C++, but were
postponed because there wasn't time to do a thorough job of exploring
the design and implementation issues. Exceptions were considered
essential for error handling in programs composed out of separately
designed libraries. The actual design of the C++ exception mechanism
stretched from 1984 to 1989."
Now go do your own research... ;-)
I agree we need exceptions in the language and they are a useful
feature. But do we really need exceptions to be type-oriented ?
Couldn't we all manage with just one exception class?
We do try..catch somewhere and where we catch we can examine the
exception if appropriate and take the right action, possibly rethrowing
it or throwing a new one.
Most of the time I have seen developers who write their own exception
classes tend to put in a numeric value as well as text. I sometimes
embed the numeric value into the string with a tab separator to have
that effect, but I find on the whole I am throwing only standard
exceptions and that runtime_error actually suffices.
If the one exception class used a code as well as text, some of the
error codes could be standard.
Now, I ask, what would be the difference in overhead to having one
exception class and typed exceptions with regards to the compiler and
the code generated etc. Would the systems that currently reject C++
exceptions start using the one class?
For the sake of portable code, we could employ the current syntax and
have this one exception class derive from std::runtime_error.
Compilers on the smaller system would probably give an error if the
detected any type being thrown other than the one exception class.
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.
Earl Purple wrote:
Alf P. Steinbach wrote:
I pulled that quote from <url:
http://www.research.att.com/~bs/hopl2.pdf>, where he further writes that
"Exceptions were considered in the original design of C++, but were
postponed because there wasn't time to do a thorough job of exploring
the design and implementation issues. Exceptions were considered
essential for error handling in programs composed out of separately
designed libraries. The actual design of the C++ exception mechanism
stretched from 1984 to 1989."
Now go do your own research... ;-)
I agree we need exceptions in the language and they are a useful
feature. But do we really need exceptions to be type-oriented ?
Couldn't we all manage with just one exception class?
We do try..catch somewhere and where we catch we can examine the
exception if appropriate and take the right action, possibly rethrowing
it or throwing a new one.
I suspect that allowing the compiler to create a table based on type
and jumping to the correct handler instead of comparing to a string to
find out what error condition you are dealing with is faster. I have
no real numbers to back up that claim though...only an assumption based
on the O().
>
Most of the time I have seen developers who write their own exception
classes tend to put in a numeric value as well as text. I sometimes
embed the numeric value into the string with a tab separator to have
that effect, but I find on the whole I am throwing only standard
exceptions and that runtime_error actually suffices.
Certainly deriving from a standard exception is appropriate and usually
allows you to create your own with a minimum of extra code and no
changes to the interface.
>
If the one exception class used a code as well as text, some of the
error codes could be standard.
I still suspect that the static typing jump is faster than a runtime
comparison of exception codes.
>
Now, I ask, what would be the difference in overhead to having one
exception class and typed exceptions with regards to the compiler and
the code generated etc. Would the systems that currently reject C++
exceptions start using the one class?
You might get a little space savings in your executable at the cost of
some speed overhead created by checking error codes. I don't expect a
really great difference either way though. Might be worth testing...
blangela wrote:
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++.
Here we have some opinions from the horse's mouth. http://www.technologyreview.com/InfoTech/17831/
-Ramon
Noah Roberts wrote:
Earl Purple wrote:
We do try..catch somewhere and where we catch we can examine the
exception if appropriate and take the right action, possibly rethrowing
it or throwing a new one.
I suspect that allowing the compiler to create a table based on type
and jumping to the correct handler instead of comparing to a string to
find out what error condition you are dealing with is faster. I have
no real numbers to back up that claim though...only an assumption based
on the O().
It may or may not be faster. If the standard exception has an
enumerated code as well as text though, you can do a switch on the code
or on bits set in the code, which is a lot faster than parsing strings.
Much of the time, you don't care what exception happened though. You
want to log the text as a task failure and continue. You might already
know what to do by when it was thrown rather than what was thrown.
In addition, it is important to note that exception throwing should be
rare and it is unlikely that you are going to performance test based on
it, especially if the extra action is a minor one such as parsing a
string or checking the bits of an integer.
If the one exception class used a code as well as text, some of the
error codes could be standard.
I still suspect that the static typing jump is faster than a runtime
comparison of exception codes.
I doubt it is, and even if so, it is probably not enough to justify the
overhead.
Now, I ask, what would be the difference in overhead to having one
exception class and typed exceptions with regards to the compiler and
the code generated etc. Would the systems that currently reject C++
exceptions start using the one class?
You might get a little space savings in your executable at the cost of
some speed overhead created by checking error codes. I don't expect a
really great difference either way though. Might be worth testing...
Just a little space savings? We are talking about a whole community
here that does not use exceptions at all because of the enormous
overhead. I am just wondering how much of this overhead is
type-checking based. Remember that the types are checked at the time
the exceptions are thrown and caught, not at compile time.
Having just the one exception still gives you the advantage over having
none at all, i.e. it will jump out of the block at the point the error
occurs, thus you can be sure that, at a point in a block of code, that
no error has occurred up to this point. It will mean there is no need
to create objects in a "zombie" state because you couldn't throw from
its constructor.
"Mirek Fidler" <cx*@ntllib.orgwrote in message
news:11**********************@j44g2000cwa.googlegr oups.com...
>
Chris Thomasson wrote:
>Well, you can't use it as a 100% drop in replacement right now because
the
interface is a little different. However, it does provides two smart
pointers:
Well, before going into details....
Have you found a way how to implement lock-free reference counting
usable e.g. for COW string? (with "weak" guarantee for string itself)?
If yes, what is the idea, if you are willing to share?
http://groups.google.com/group/comp....8aa9fe4d0d823e
In order for this to work I have to add CAS to the library... Humm, Well,
here is the source code for the CAS functions:
(mingw-gas)
--------------
..align 16
# int refcount_ia32_cas(
# refcount_ia32_t* volatile*,
# refcount_ia32_t*,
# refcount_ia32_t*)
..globl _refcount_ia32_cas
_refcount_ia32_cas:
MOVL 4(%ESP), %ECX
TESTL %ECX, %ECX
JE refcount_ia32_cas_failed
MOVL 8(%ESP), %EAX
MOVL 12(%ESP), %EDX
LOCK CMPXCHGL %EDX, (%ECX)
CMPL %EAX, 8(%ESP)
JNE refcount_ia32_cas_failed
MOVL $1, %EAX
RETL
refcount_ia32_cas_failed:
XORl %EAX, %EAX
RETL
..align 16
# int refcount_ia32_add_cas_weak(
# refcount_ia32_t* volatile*,
# refcount_ia32_t*,
# refcount_ia32_t*,
# int)
..globl _refcount_ia32_add_cas_weak
_refcount_ia32_add_cas_weak:
MOVL 4(%ESP), %ECX
TESTL %ECX, %ECX
JE refcount_ia32_cas_failed
MOVL 12(%ESP), %EDX
TESTL %EDX, %EDX
JE refcount_ia32_add_cas_weak_execute
MOVL 16(%ESP), %EAX
CMPL $0, %EAX
JLE refcount_ia32_add_cas_weak_execute
LOCK XADDL %EAX, (%EDX)
refcount_ia32_add_cas_weak_execute:
MOVL 8(%ESP), %EAX
LOCK CMPXCHG %EDX, (%ECX)
CMPL %EAX, 8(%ESP)
JNE refcount_ia32_add_cas_weak_dec
MOVL $1, %EAX
RETL
refcount_ia32_add_cas_weak_dec:
TESTL %EDX, %EDX
JE refcount_ia32_add_cas_weak_failed
CMPL $0, 16(%ESP)
JLE refcount_ia32_add_cas_weak_failed
LOCK DECL (%EDX)
refcount_ia32_add_cas_weak_failed:
XORL %EAX, %EAX
RETL
If you want to use CAS with my refcount library now, just stick the posted
source code in the refcount-ia32-mingw.asm file and assemble... Then create
the declarations in the refcount-ia32.h file, and add the proper member
functions to the refcount-sys.hpp and refcount.hpp files... Simple...
;^)
I am going to add the CAS to my library very soon, I will definitely keep
you posted. Okay?
:^)
Earl Purple wrote:
Just a little space savings? We are talking about a whole community
here that does not use exceptions at all because of the enormous
overhead.
Yeah, I've talked to those people. As far as I can tell not a one has
any objective information to back up the claim that there even is any
overhead much less enormous overhead. Some have minimal experience
with some compiler they used in the 90's that handled exceptions poorly
and have never bothered to look at anything more modern...those are the
_most_ informed.
ACK! Those were crappy old versions...
Here is the newest ones:
..align 16
# int refcount_ia32_cas(
# refcount_ia32_t* volatile*,
# refcount_ia32_t*,
# refcount_ia32_t*)
..globl _refcount_ia32_cas
_refcount_ia32_cas:
MOVL 4(%ESP), %ECX
TESTL %ECX, %ECX
JE refcount_ia32_cas_failed
MOVL 8(%ESP), %EAX
MOVL 12(%ESP), %EDX
LOCK CMPXCHGL %EDX, (%ECX)
JNE refcount_ia32_cas_failed
MOVL $1, %EAX
RETL
refcount_ia32_cas_failed:
XORl %EAX, %EAX
RETL
..align 16
# int refcount_ia32_add_cas_weak(
# refcount_ia32_t* volatile*,
# refcount_ia32_t*,
# refcount_ia32_t*,
# int)
..globl _refcount_ia32_add_cas_weak
_refcount_ia32_add_cas_weak:
MOVL 4(%ESP), %ECX
TESTL %ECX, %ECX
JE refcount_ia32_cas_failed
MOVL 12(%ESP), %EDX
TESTL %EDX, %EDX
JE refcount_ia32_add_cas_weak_execute
MOVL 16(%ESP), %EAX
CMPL $0, %EAX
JLE refcount_ia32_add_cas_weak_execute
LOCK XADDL %EAX, (%EDX)
refcount_ia32_add_cas_weak_execute:
MOVL 8(%ESP), %EAX
LOCK CMPXCHG %EDX, (%ECX)
JNE refcount_ia32_add_cas_weak_dec
MOVL $1, %EAX
RETL
refcount_ia32_add_cas_weak_dec:
TESTL %EDX, %EDX
JE refcount_ia32_add_cas_weak_failed
CMPL $0, 16(%ESP)
JLE refcount_ia32_add_cas_weak_failed
LOCK DECL (%EDX)
refcount_ia32_add_cas_weak_failed:
XORL %EAX, %EAX
RETL
Can you notice the difference between the crap code and this code? Hint...
It has something to do with redundant condition codes...
;^)
ACK! Those were crappy old versions...
Well, I must say that you are posting a lot of links to code, but
little explanation, I hope you would not mind if I place several stupid
beginner questions to get myself oriented... (I also do not have enough
time to harvest all informations over inet).
LOCK CMPXCHGL %EDX, (%ECX)
LOCK XADDL %EAX, (%EDX)
LOCK CMPXCHG %EDX, (%ECX)
LOCK DECL (%EDX)
Are these considered lock-free? Or they are used in "slow path" only?
If they are consideed lock-free, is there a performance difference
between CAS (LOCK CMPXCHGL %EDX, (%ECX)) and atomic increment/decrement
(LOCK DECL (%EDX))?
Mirek
"Mirek Fidler" <cx*@ntllib.orgwrote in message
news:11**********************@16g2000cwy.googlegro ups.com...
>ACK! Those were crappy old versions...
Well, I must say that you are posting a lot of links to code, but
little explanation, I hope you would not mind if I place several stupid
beginner questions to get myself oriented... (I also do not have enough
time to harvest all informations over inet).
> LOCK CMPXCHGL %EDX, (%ECX)
> LOCK XADDL %EAX, (%EDX)
LOCK CMPXCHG %EDX, (%ECX)
> LOCK DECL (%EDX)
Are these considered lock-free?
Yes. They do assert the bus lock signal, but that different than using a
mutex: http://groups.google.de/group/comp.p...d5c6aa62e8f876
(this might clear some thing up for you...)
Or they are used in "slow path" only?
The only place where my algorithm makes use of a lock is in the
refcount_ia32_add_load_strong(...) function, and when the
refcount_ia32_sub_strong(...) drops the reference count to zero. Other than
that, everything is 100% lock-free.
If they are consideed lock-free, is there a performance difference
between CAS (LOCK CMPXCHGL %EDX, (%ECX)) and atomic increment/decrement
(LOCK DECL (%EDX))?
Not really. Except you can't use atomic increment/decrement alone to get
strong thread safety.
Chris Thomasson wrote:
"Mirek Fidler" <cx*@ntllib.orgwrote in message
news:11**********************@16g2000cwy.googlegro ups.com...
ACK! Those were crappy old versions...
Well, I must say that you are posting a lot of links to code, but
little explanation, I hope you would not mind if I place several stupid
beginner questions to get myself oriented... (I also do not have enough
time to harvest all informations over inet).
LOCK CMPXCHGL %EDX, (%ECX)
LOCK XADDL %EAX, (%EDX)
LOCK CMPXCHG %EDX, (%ECX)
LOCK DECL (%EDX)
Are these considered lock-free?
Yes. They do assert the bus lock signal, but that different than using a
mutex:
Actually, I always thought that basic Win32 mutex (CRITICAL_SECTION) is
(in fast path) nothing more than single CAS operation...
Anyway, "LOCK CMPXCHGL %EDX, (%ECX)" is still about 400 times slower
than regular non-LOCK-ed operation, AFAIK.
I was sort of hoping that you found a way around this LOCK :)
If they are consideed lock-free, is there a performance difference
between CAS (LOCK CMPXCHGL %EDX, (%ECX)) and atomic increment/decrement
(LOCK DECL (%EDX))?
Not really. Except you can't use atomic increment/decrement alone to get
strong thread safety.
Confused a bit again.
Say I have COW String, I am serializing the accesses to it (mutex for
both read and write), I always thought that atomic increment/decrement
of shared count is enough to keep me safe?
Does strong safety here mean that I would be able to read and/or write
the String without locking?
( Who needs it? :-) )
Thanks for explaining.
"Mirek Fidler" <cx*@ntllib.orgwrote in message
news:11*********************@j72g2000cwa.googlegro ups.com...
>
Chris Thomasson wrote:
>"Mirek Fidler" <cx*@ntllib.orgwrote in message
news:11**********************@16g2000cwy.googlegr oups.com...
>ACK! Those were crappy old versions...
Well, I must say that you are posting a lot of links to code, but
little explanation, I hope you would not mind if I place several stupid
beginner questions to get myself oriented... (I also do not have enough
time to harvest all informations over inet).
[...]
>
Are these considered lock-free?
Yes. They do assert the bus lock signal, but that different than using a
mutex:
Actually, I always thought that basic Win32 mutex (CRITICAL_SECTION) is
(in fast path) nothing more than single CAS operation...
Consider the fact that the interlocked instruction used for CRITICAL_SECTION
does not operate on the shared data you want to alter. It only operates on
the lock state. And, you have to take into account that a lock has to be
unlocked. Thats another interlocked instruction.
So, if you measure a 100% uncontended lock-free operation vs. a 100%
unconteded lock-based operation you get this:
lock-free update if a word
------------------------
1 interlocked instruction
lock-based update of a word
-----------------------------
2 interlocked instructions
1 store
-- The interlocked instruction in the lock-free performed the update
directly to the word.
-- The interlocked instructions in the lock-based performed the update on
the locks internal state. The store instruction actually updated the word...
IMO, the lock-free stuff is a winner... Now if you take contention into
account, well, the lock-based stuff might have to park threads in the
kernel! The lock-free will not...
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...
;^)
Anyway, "LOCK CMPXCHGL %EDX, (%ECX)" is still about 400 times slower
than regular non-LOCK-ed operation, AFAIK.
I was sort of hoping that you found a way around this LOCK :)
If they are consideed lock-free, is there a performance difference
between CAS (LOCK CMPXCHGL %EDX, (%ECX)) and atomic increment/decrement
(LOCK DECL (%EDX))?
Not really. Except you can't use atomic increment/decrement alone to get
strong thread safety.
Confused a bit again.
Say I have COW String, I am serializing the accesses to it (mutex for
both read and write), I always thought that atomic increment/decrement
of shared count is enough to keep me safe?
If you perform the atomic increments under the protection of the lock, then
you will be fine.
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.
Mirek Fidler wrote:
Chris Thomasson wrote:
Actually, I always thought that basic Win32 mutex (CRITICAL_SECTION) is
(in fast path) nothing more than single CAS operation...
Anyway, "LOCK CMPXCHGL %EDX, (%ECX)" is still about 400 times slower
than regular non-LOCK-ed operation, AFAIK.
I was sort of hoping that you found a way around this LOCK :)
Branch logic is almost as expensive as an inline LOCK. In multi-core
will become the norm, unconditional LOCK is probably the most efficient.
>
>>>If they are consideed lock-free, is there a performance difference
between CAS (LOCK CMPXCHGL %EDX, (%ECX)) and atomic increment/decrement
(LOCK DECL (%EDX))?
Not really. Except you can't use atomic increment/decrement alone to get
strong thread safety.
Confused a bit again.
Say I have COW String, I am serializing the accesses to it (mutex for
both read and write), I always thought that atomic increment/decrement
of shared count is enough to keep me safe?
Does strong safety here mean that I would be able to read and/or write
the String without locking?
( Who needs it? :-) )
Maybe not for String, but for the more complex data structures like
collections lock-free beats anything else out there in solving
the reader/writer problem.
--
Joe Seigh
When you get lemons, you make lemonade.
When you get hardware, you make software.
Once you acquire a strong reference to you string object, you can do
lock-free COW via. CAS.
The basic idea is:
pseudo-code
---------------
typedef std::string mystring_t;
typedef vzsync::ptr::global<mystring_tmystring_gptr_t;
typedef mystring_gptr_t::local_t mystring_lptr_t;
static mystring_gptr_t s_buf(new mystring_t("hello"));
void do_cow_cas(mystring_t const &src) {
mystring_lptr_t xchg(new mystring_t), cmp;
do {
cmp = s_buf;
if (cmp) {
xchg->append(src);
}
} while(s_buf.cas(cmp, xchg));
}
or you can do a 100% lock-free swap like this:
void do_swap_weak(mystring_lptr_t &dest, mystring_t const &src) {
dest->append(src);
s_buf = dest;
}
There are more tricks... However, are you having trouble understanding the
pseudo-code?
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?
ARGHGGH!
void do_cow_cas(mystring_t const &src) {
mystring_lptr_t xchg(new mystring_t), cmp;
do {
cmp = s_buf;
if (cmp) {
Need to add this of course!!!
xchg->assign(*cmp);
xchg->append(src);
}
} while(s_buf.cas(cmp, xchg));
}
sorry for any confusion!
;^(...
"Mirek Fidler" <cx*@ntllib.orgwrote in message
news:11**********************@n67g2000cwd.googlegr oups.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...
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.
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...
"Earl Purple" <ea********@gmail.comwrote in message
news:11*********************@80g2000cwy.googlegrou ps.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
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_SECTION 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
"Mirek Fidler" <cx*@ntllib.orgwrote in message
news:11**********************@14g2000cws.googlegro ups.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_SECTION 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.
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/
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 "programming 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 "programming 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".
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
Chris Thomasson wrote:
"Mirek Fidler" <cx*@ntllib.orgwrote in message
news:11**********************@14g2000cws.googlegro ups.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_SECTION 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.
Ah, I guess I am getting into terminology :) This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: David Eng |
last post by:
> For many years now enterprise business application development has
> been the core area for the use of C++.
> Today a significant share to this segment has already been lost to
> SUN's Java...
|
by: GTO |
last post by:
I do not believe that C# is the future of C++. I also do not believe that
adding two thousand new library functions to the standard library is the
future of C++. But what is the future of C++? Is...
|
by: Lyle Fairfield |
last post by:
It's confusing. Many people here and elsewhere make many different
predictions:
There's an introduction mentioning some aspects of this at...
|
by: |
last post by:
Everything seems to be moving to .NET and VC++ seems to be adding a lot of
managed code support every new release.
The questions: is unmanaged code in VC++ beeing phased out in favour of
managed...
|
by: Fuzzyman |
last post by:
Hello all,
The following is a copy of a blog entry. It's asking a question about
future statements and the built in compile function. I'd appreciate any
pointers or comments about possible...
| | |
by: Zootal |
last post by:
My apologies if this gets asked/discussed a lot. With c# rampaging through
corporate USA (and other countries), what impact will this have on the usage
and future of c++? I've used both of them a...
|
by: rohayre |
last post by:
Im a long time java developer and actually have never done anything
with java scripting. I'd like to write a short simple script for
calculating a date in the future based on today's date and a...
|
by: KimmoA |
last post by:
Does C have a future? I'd like to think so, but nobody seems to agree
with me. Of course, I don't use C in my profession, and maybe I
wouldn't be using it if I had the pressure to actually produce...
|
by: Jon Harrop |
last post by:
If Microsoft turn F# into a product and place it alongside C# and VB, will
many people migrate from C# to F#?
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
| | |
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...
| | |
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence...
| |
