Heads-up: volatile and C++

[Marcin Dalecki]

On 2005-04-16, at 00:38, Mike Stump wrote:
>
> Seriously, what does that have to do with anything?

Well perhaps my view is somehow shed by the project I'm currently 
sitting on.
It's actually kernel programming. And this occurs for me quite to be 
quite the kind of
stuff, which may be very well put this kind of object serialization to 
good use...

> I know, let's not recommend C for device driver programming, because 
> there doesn't exist a C compiler that doesn't have a bug in the world.

Actually I see you point and agree. However what one really needs for 
device driver programming
is actually a super-set of C.

> My claim would be, there is a reasonable portable subset of C, or C++ 
> that one can use in their endeavors.  Further, while in 1992, this 
> subset maybe didn't reasonably include templates, that in 2005, it 
> does.
>
> If for you, it doesn't, well, ok, fine.

OK agreed.

> Go research why that thing that I refuse to even name, doesn't include 
> templates, report back here, when you have the answer.

As you already pointed out the reasons stated that long ago are of no 
particular argumentative
interest nowadays. However the conclusions itself may still be valid 
for other reasons.
Well as a side note - my main problems with templates are not the ideas 
involved here. Or the
coding style design paradigmas it permits.
However there are serous validation concerns in shed of the seemingly 
always evolving
and very very extensive specification. It looks like there is always a 
corner case in behavior
which has to be plunged in the next standard revision. Template driven 
code too tends to be somehow
immune to even simpler things like independent peer review. There are 
pragmatical deficiencies in
*all* the implementations I had to deal with thus far. There are 
related maintenance problems over
time and when changing compilers. And so on. However I fully agree that 
those points don't apply
universally  and there are a lot of valid uses of the whole C++ set. I 
recognize as well that
in the case of GCC itself the implementation of this facility got much 
much better during recent years.

I just don't agree that something specified as a subset guided 
effectively at the lie of exclusion of
all language constructs which can be described as conceptually 
difficult should be dismissed straight
away. It can be useful if only for example for the case where you have 
some people with truly bad habits on
your team to put a stop gap on them. (Most of template driven code out 
there written in house sure as
hell didn't look exactly pretty thus far to me...)

>  Don't accept the marketing explanation either.

Agreed. Maybe the idea of a subset of C++ basically coming down what 
would be a C with inheritance
was somehow over-hyped by too much marketing bragging as an excuse for 
some defective C++ compiler
implementation at introduction? Thus you still have grief memories 
about it?

>   I can then check, and see if your answer matches mine.  We can then 
> discuss if, at the time, it made for a good decision for the so named 
> subset, it did not.

Well I don't thing it's a question of good or bad. It's more like a 
question of whatever it's sufficiently
usefull.