🚀 go-pugleaf

[ Note: I'm drifting quite off-topic here, so I set followups to 
        comp.lang.c++ ]

>>>>> "JK" == Jeff Koftinoff <jeffk@kelowna.awinc.com> writes:
JK> David Vandevoorde (vandevod@cs.rpi.edu) wrote:
JK> : >>>>> "JK" == Jeff Koftinoff <jeffk@kelowna.awinc.com> writes:
[...]
JK> I like and use templates a lot too. I've been wanting to use them for
JK> about three years, since I do multi-platform development.  
JK> Only now do enough compilers on the different platforms support them in a 
JK> non-brain-dead way.  I like gcc's -frepo flag.   

Yes, the -frepo patch is very nice, but things are still very buggy.
I have to cope with portability issues also; as a result, I try to
limit my template code to things that can be inlined. As it turns out,
this is often reasonable... in the future when all my code will consist
of templates, I imagine it won't be.

[...]
JK> : C++ exceptions are synchronous; throwing from an (asynchronous)
JK> : interrupt handler may not be a good idea.

JK> Is there any way to guarantee that, though? It is not just interrupt
JK> handlers that have to worry - Different threads do too.

Exactly: inter-thread signaling is also asynchronuous and the C++
exception model fails again. This is one of the many reasons why I
think C++ exceptions are not a major boon: they are sometimes useful,
but often not. Even in the cases where they are useful, I've always
had reasonable alternative handling styles and, considering the current
effects on optimizability, I think I prefer the alternatives anyway.

[...]
JK> 	const MyClass & operator [] ( int n ) const;
JK> 	MyClass & operator [] ( int n );
[...]
JK> What do you return if n is out of bounds, or if something more complex
JK> goes wrong?  It can't be NULL or anything like that! maybe you have
JK> to hardwire an assert() or exit(), but then the user of your
JK> class can't catch the error.
[... part of the elided text somewhat hints at what follows ]

The following behavio(u)rs are commonly encountered:
     1) dynamic expansion: out-of-bounds is not an error, but an indication
	that the bounds must be updated,
     2) default value: out-of-bounds is not an error, but a reference to
	a default location (usually a hack, really),
     3) fatal error: out-of-bounds is an error and cannot be handled;
	(graceful?) termination is required,
     4) local error: out-of-bounds is an error but can be handled by the
	target object (e.g., default value + log problem somewhere,
	prompt user for a value, ...)
     5) recoverable error: out-of-bounds is an error and cannot be handled
	by the target; presumably the caller or one of its parents can
	handle the unexpected situation.
I think C++ exceptions are only really useful to handle case 5 (arguably
a frequent case); however, I don't think non-exception-based solutions
are necessarily ``ugly''.

Unfortunately, it is often not known beforehand which policy applies.
In fact, a same class may very well be useful with different policies;
I prefer to handle this as one class (template) with installable
handlers rather than many classes with specific failure (or recovery)
modes.

[...]
JK> If you have constructors that can't fail, you don't need
JK> exceptions.

Indeed. (Could say much more :)

JK> If it can fail, it will eventually.  If you are writing mission

Probably.

JK> critical code, you HAVE to anticipate and deal with it, in some way.
JK> exceptions are a nice way.

They are (IMO). Fortunately, they are not the only way and, IMO, not
the only ``nice'' way. Avoiding the necessity for exceptions introduces
some constraints; exceptions introduce some other (arguably less
stringent, but no less critical) constraints.

[...]
JK> : JK> There is now brand new syntax for this.  Follow comp.std.c++.

JK> : I do, thanks. The syntax is quite new indeed in the sense that AFAIK
JK> : no compiler implements it yet. The April DWP did mention this already
JK> : though.  For those not following the evolution of the DWP, the above
JK> : example would become (if you want to catch an exception from the
JK> : ctor-initializer):

JK> : 	MyClass::MyClass() try: my_var(1, 2, 3, 4) {
JK> : 	    // ...
JK> : 	} catch (// ...

JK> : JK> Basically, for Kernel design in c++ you would have to limit
JK> : JK> yourself to a little bit more than the level of c++ implemented on
JK> : JK> the Macintosh with 'Think Technologies C' compiler (now Symantec
JK> : JK> THINK C) in 1988.
JK> : [...]

JK> : 1988 is pre-ARM. I think many ARM (e.g., templates) and post-ARM
JK> : (e.g., namespaces) features could be exploited for kernel design. I
JK> : believe the C++ exception model would not be appropriate though (or at
JK> : least: insufficient).

JK> Yes, namespaces, when they exist would be good.  Simple templates are good.

They `exist' :-) I know of two compilers that implement them (and just
got one of those :).

JK> What I would like to see is a 'standard' way to shut off exception 
JK> handling on a per-method/function/class level.  That way we can

Well, this is actually mostly in place. E.g., for memory allocation
you can use `new(nothrow)', substitute your own `new' or even install
a new-handler that doesn't fail (similar for array-versions).

I must say I prefer the proposed I/O-library's philosophy: don't
throw exceptions unless requested.

[...]
JK> Unfortunately, the code I write that must be portable does not use
JK> exceptions.  Because many compilers don't handle them.   So I have
JK> to be very careful with constructors and operators. I have to have
JK> my own error handling class, and I have to write my code to
JK> explicitly check all return codes.

Yes, I also opted for failure-modes relying on my own facilities
(i.e., no exceptions).

JK> Once exceptions are robust on all the platforms I need, then I
JK> will move to them.

Good luck :-)

[...] 
JK> The C++ language and C++ compilers in general right now are not
JK> mature enough to write a real kernel in, unless you limit
JK> the nice C++ features that you use.
[...]

I think a substantial part of C++ is well enough understood that it
could be applied to kernel design/development (I'm not saying that
Linux should go that way; I'm no Linux kernel hacker). OTOH, there are
a few features with which I have not enough experience to make
conclusions about when or where to use them. However, missing a few
``neat features'' should not be too much of a problem if the available
mechanisms are useful, viable and reliable.

	Daveed