C or C++? (Preference for cross platform solutions)

C

Carlo Milanesi

loufoque said:
Carlo Milanesi wrote :


None of them, though, use modern C++.

It is an argument against the use of modern C++, i.e. if most successful
open source applications have avoided modern C++, perhaps they wanted to
avoid modern C++ drawbacks, or in an evelutionary vision, the projects
that adopted modern C++ did not survive.

Other explanations are:
1) Most successful open source application development began 10 years
ago, and now they stick to the programming idioms popular in that time.
2) Most successful open source applications used GCC or Microsoft Visual
C++ version 6 compilers. The former had an inefficient standard library,
and the latter do not support modern C++.

However, the dilemma of the OP wasn't between ancient C++ and modern
C++, but between C and C++. The fact is that the C++ language, albeit an
ancient one, is widely used for open source software.
 
I

Ian Bell

Sachin said:
I have been told that C++ compilers are not available for all platforms
and for many platforms they only support a basic subset of C++ features
(like just inheritance/overloading etc...). That this is especially
true for embedded platforms. Thus I am advised to use C.

Depends a lot on the platform. Many smaller micros (e.g.8 bit) can barely
support C let alone C++ because they have so few resources and such
specialised instruction sets. When you move up to processors like the ARM
its instruction set and resources make it ideal for C or C++ and compilers
for both are readily available. I guess I am saying micros with
architectures that readily cupport C/C++ have compilers available, those
that don't, don't.
I want my code to be usable on as wide variety of platforms as
possible. But I dont have much platform experience beyond coding on
windows and linux, and havnt ever tried any compiler beyond
GCC/MSVC/Borland. So I dont really know the current state of affairs.

Your first problem is that the platforms you are used to come complete with
an operating system - this is not the case in many embedded systems and
often the OS is an RTOS for obvious reasons. AFAIK most RTOSs are written
in C. What you code does will therefore strongly affect its portability -
if it is a collection of algorithms it may be highly portable, but if it is
I/O centric then it almost certainly will not.
I notice that many (almost all?) open source projects are in C, even
the new ones. Is it just because of personal choice or is it a decision
made for portability?

There are plenty of C++ open source projects and the relative proportion is
increasing but few if any are embedded so I am not sure how relevant this
point is.
I am a hard-core C++ developer totally in love with the language and
all of its (relatively) new features, it will be hard for me to do
non-object-oriented programming and write good code without using
templates/exceptions etc... I have done C coding too and it wont be
technically hard for me, but I don't want to shift to C unless it is a
really highly recommended option.

What would you choose in such a situation? If I do choose C++, how much
will it really impact the usability of my code.

I think there is no 'general' answer to this question. It depends very much
on which platforms and what your code does. Tell us more about those toe
factors and maybe we can give better advice.

Ian
 
Z

Zara

Zara wrote :


The first C++ standard is from 1998.
Did you mean C++98 ?

Yes, of course. Someday I will cut my hands for making all those
typos, and will begin to use some kind of voice recognizing text
editor.

And then, I will have to lose all my time correcting the computer
writing caused by my extermely bad pronunciation ;-)


Zara
 
L

loufoque

Ian Bell wrote :
What is 'modern' C++?

C++ as it is defined now (The latest standard being from 2003), with all
the technologies it provides.

Maybe it could be defined by the use of namespaces, exceptions,
templates, RTTI and the C++ standard library (including STL) when
appropriate.
 
G

Greg Comeau

I have been told that C++ compilers are not available for all platforms
and for many platforms they only support a basic subset of C++ features
(like just inheritance/overloading etc...). That this is especially
true for embedded platforms. Thus I am advised to use C.

You have been advised upon impossible odds. That is to say,
it's true that C++ is not available for all platforms.
However, that is meaningless because it is also true that no
language is available for all platforms. IOWs, the advise has been
provided w/o a context, at least as you have mentioned it.

W.r.t a basic subset of C++ .. especially for embedded platforms,
you are probably referring to so-called EC++ (Embedded C++).
Yes, there is such a subset defined by an industry consortium group.
Also, some compilers, for instance, Comeau C++, support a mode to
support such a dialect, however, there is generally no such
requirment that that dialect be used on using C++ for applications
intended for embedded systems.

Now, the comments may have been that C is available for more
platforms than C++, and I believe that is a fact. But that in and
of itself should not preclude one for the other.
I want my code to be usable on as wide variety of platforms as
possible.

But how possible? IOWs, you partially get to define how
far the net is cast. There are various multi-platform compilers
(gcc, Comeau, etc). Also, of this possiblity you do not mention
embedded platforms, so it is unclear if that is a hypothetical
concern or an actual concern of yours.
But I dont have much platform experience beyond coding on
windows and linux, and havnt ever tried any compiler beyond
GCC/MSVC/Borland. So I dont really know the current state of affairs.

That's a quantifiable starting point, but probably you need to define
your ending point better than "all platforms", as that is probably
unrealistic, unachievable, etc. even in the long term. Even saying
"all popular platforms" would need to be tamed.
I notice that many (almost all?) open source projects are in C, even
the new ones. Is it just because of personal choice or is it a decision
made for portability?

Could be for many reasons. However, if many == almost all, I could not
imagine that's true though.
I am a hard-core C++ developer totally in love with the language and
all of its (relatively) new features, it will be hard for me to do
non-object-oriented programming and write good code without using
templates/exceptions etc... I have done C coding too and it wont be
technically hard for me, but I don't want to shift to C unless it is a
really highly recommended option.

You probably need to say more. For instance, how deep is your
C++ investment? You being in love with C++ may be different than
your firm having already spend millions on the project in COBOL.
And so on.
What would you choose in such a situation? If I do choose C++, how much
will it really impact the usability of my code.

C++, and applications, is popular and available on many platforms.
For a sampling see http://public.research.att.com/~bs/applications.html
ps, I am considering another option (which probably will get tossed out
of window by some of you :). Maybe I can just code it all in C++ the
way I want and port it to C when (and if) need arises.

That has at least two problems. The first is that the "porting"
effort is non-trivial for even most small applications.
The second is that the "port" may look different depending
upon the features of each respective language.
I am hoping that
by the time need arises, the compilers would have improved.

Improved in which ways? What is the limitation you are considering?
Another thought (rather a wish ;-), are there any good/reliable
translating compilers, which can translate my template and exception
heavy C++ code to C without hurting code's run-time efficiency too
much? Google gave me this disappointment:
http://en.wikipedia.org/wiki/Cfront :)

Comeau C++ can, although exceptions take a hit.
However, it is not clear how this helps your situation?
 
G

Greg Comeau

Agreed, exceptions and RTTI etc probably should be avoided due to
overhead.

Also, I read that C++ to C translators use longjmp to implement
exceptions and I recall that I was asked not to use longjmp when coding
for embedded systems. So it all fits in :)

A few years back it was considered that exceptions and iostreams
were considered excessive for many embedded systems. That is
probably still still in most cases. This assumes they can even
be supported at all. BTW, in many cases, even Standard C
is often not provided in full for some embedded systems use.
Thanks, I googled a bit for this and landed here:

http://www.embedded.com/97/feat9712.htm

I dont understand why they eliminated templates and namespaces. IMHO
these are just compile time tools which have no run-time overhead. Best
reason I can think of is that templates were too new back then, or
their compiler implementers were probably lazy (I could be wrong :)
Maybe they will someday reconsider adding these. It seems to be a good
middle path to choose, something is better than nothing.

I agree some parts should be neither here nor there, especially
when performance is the reason given. In some cases I think they
did want to be able to find consistent implementations but the
rationale seems to have being misworded.
 
G

Greg Comeau

I landed here almost immediatly after I posted my original message.
This seems impressive. Anyone knows how good they are with templates?

Comeau C++ supports templates well. In many cases, it was the
first compiler to provide a template feature, including "clarifications"
found in C++03.
 
G

Greg Comeau

My advice, if you are going to program embedded systems: *do use C++*.
*do not enable exceptions*.*remember to check for NULL pointers on
alloc/new return*

For some embedded systems this is one tradeoff which needs to
be made. Of course, on other systems, "enen C" has too much
overhead, for instance, in some cases, "even malloc" is something
to be avoided, or customized.
 
G

Greg Comeau

It is an argument against the use of modern C++, i.e. if most successful
open source applications have avoided modern C++, perhaps they wanted to
avoid modern C++ drawbacks, or in an evelutionary vision, the projects
that adopted modern C++ did not survive.

I agree it could mean those things. But that would fly against
non-OS projects using C++. It would also fly against OS ones (for
instance OpenWBEM, also nullsoft and Sun's openoffice stuff come to
mind immediately too, though I don't know whether they've moderized or not).
(I'm not negating what you said, rather added to it.)
Other explanations are:
1) Most successful open source application development began 10 years
ago, and now they stick to the programming idioms popular in that time.
2) Most successful open source applications used GCC or Microsoft Visual
C++ version 6 compilers. The former had an inefficient standard library,
and the latter do not support modern C++.

Some of that probably is true in some cases (I recall hearing such
arguments at the time in some cases), but I think the lack of
C++ API rules as the culprit in many cases, especially for embedded
systems programming. For instance, on the latter we are often asked
to produce C for folks ala Comeau C++ because a chip only has a C compiler
(and hence a C API) but really that's only the 1/2 of it, and somewhat
misguided. Though clearly a solution can be presented (providing a C++
compiler that works in unison with what is available).
However, the dilemma of the OP wasn't between ancient C++ and modern
C++, but between C and C++. The fact is that the C++ language, albeit an
ancient one, is widely used for open source software.

I agree.
 
G

Greg Comeau

Depends a lot on the platform. Many smaller micros (e.g.8 bit) can barely
support C let alone C++ because they have so few resources and such
specialised instruction sets. When you move up to processors like the ARM
its instruction set and resources make it ideal for C or C++ and compilers
for both are readily available. I guess I am saying micros with
architectures that readily cupport C/C++ have compilers available, those
that don't, don't.

IOWs, in many cases not even Standard C is supported fully,
so why should C++ be? :)
Your first problem is that the platforms you are used to come complete with
an operating system - this is not the case in many embedded systems and
often the OS is an RTOS for obvious reasons. AFAIK most RTOSs are written
in C.
Yes.

What you code does will therefore strongly affect its portability -
if it is a collection of algorithms it may be highly portable, but if it is
I/O centric then it almost certainly will not.

Yes, but that's more or less language neutral, IOWs, this pro and con
for both C and C++.
There are plenty of C++ open source projects and the relative proportion is
increasing but few if any are embedded so I am not sure how relevant this
point is.

Also, how many _100% new_ OS projects are embedded related?
Most I'm aware of seem based on existing systems.
 
S

Sachin Garg

Zara said:
<...>


Be careful!

Whatever you use, being C++, tends to grow too much *for embedded
systems* if exceptions are enabled.

I am writing a whole embedded system (RTOPS included) in C++ with only
a under lines of assembler code (well, it is impossible to go without
it), and *no* C lines at all.

Code size grown expnentially if exceptions are allowed, so I have to
write in a C++ dialect that is almost pre C++89 standrad (but with
templates, namespaces and other nice features vetoed by EC++).

My advice, if you are going to program embedded systems: *do use C++*.
*do not enable exceptions*.*remember to check for NULL pointers on
alloc/new return*

"NULL pointers on alloc/new return" is definitely something the likes
of me (new to embedded systems) can forget very easily :)

Sachin Garg [India]
www.sachingarg.com | www.c10n.info
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,776
Messages
2,569,603
Members
45,200
Latest member
LaraHunley

Latest Threads

Top