public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Shiv Shankar Ramakrishnan" <ShivShanks@MailandNews.com>
To: <gcc@gcc.gnu.org>
Cc: <shebs@apple.com>
Subject: RE: Whatever happened to -fembedded-cxx?
Date: Wed, 22 Mar 2000 22:48:00 -0000	[thread overview]
Message-ID: <000701bf9494$3f2bd0d0$8d02a8c0@intranet.pspl.co.in> (raw)

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.

             reply	other threads:[~2000-03-22 22:48 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-03-22 22:48 Shiv Shankar Ramakrishnan [this message]
  -- strict thread matches above, loose matches on Subject: below --
2000-03-22 18:20 Mike Stump
2000-03-22 14:20 Stan Shebs
2000-03-22 15:54 ` Martin v. Loewis
2000-03-22 17:19   ` Jeffrey A Law

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='000701bf9494$3f2bd0d0$8d02a8c0@intranet.pspl.co.in' \
    --to=shivshanks@mailandnews.com \
    --cc=gcc@gcc.gnu.org \
    --cc=shebs@apple.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).