This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: Whatever happened to -fembedded-cxx?


Hi,

> (In case anybody is wondering why EC++ has reared its ugly head again,

I think EC++ is just a fancy name and a wrong way to address some of the
*percieved* problems in C++. As to why you should care about my opinion?
Well for one as a person who has recently understood why the Std C++
makes a lot of sense and why no other language comes close to offer all
that it does. Also I figured out that EC++ doesn't cut it at all inspite
of my having just about 1 year of real world C++ experience. You can
think of my views as how a till recently an outsider thinks about it.

I sometimes really think EC++ was dreamt up by people who didn't and
couldn't implement the whole Std C++ language. For example just why in
the world have they left namespaces and new style casts out of it?!
They features have absolutely NO runtime time/space costs. So aren't
they contradicting themselves? Rather at least the new style casts
(though they look unpretty) would be very usefull in embedded progra-
mming since then you can easily scan all typecasts that might be causing
crashes. I wonder if they are really helping embedded programming.

Also templates *may* cause code bloat but no speed loss. In fact C++ is
the only language that has come close matching the speed of optimised
Fortran for high performance scientific computing. Have a look at
http://www.oonumerics.org/blitz/
Do peruse through some papers there to expand your knowledge of what C++
can really do. So why have templates been totally dropped from EC++?!
Okay speed may not always be critical in embedded systems but it is for
Real Time embedded systems.

Still not convinced then please read what Stroustrup himself says on
EC++ -
http://www.research.att.com/~bs/bs_faq.html#EC++

> Apple is specifying EC++ for its I/O driver kit for OS X.

If Apple really wants to use C++ for the I/O driver kit then they should
rather have coding guidelines for not using features like exceptions
or RTTI (which might decrease runtime speed), and NOT by giving credence
to another subset of C++ that is going to confuse people and send all
the wrong signals. It is highly undesirable to use EC++ when the 
Standard is out. And this is a single platform thing so why should Apple
be worried about noncompliant compilers esp. that it might use GCC?

I really wish all the compiler vendors would pull up their socks and
have Std comforming compilers. For example partial template 
specialization is important for reducing template code boat, but many
commercial compilers don't implement it. If GCC can do it why not all
of them? I sometimes get really pissed off that I can't use even a
decent subset of std C++ due to the horrible mess that happens with
if you want to be cross platform/compiler. Sure you can stick to a
subset of C++ for that, (for the time being till things get better) but
doing that formally by something like EC++ is to discredit and belittle
the whole standards C++ process.

Thanks,
Shiv

Disclaimer -
Please regard the above as my personal opinion only. Others may disagree.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]