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

[Sachin Garg]

I know that language choices are more of a religious choice, rather
than a logical decision for many of us. Anyway, here is my concern
(which will hopefully not be considered a troll)

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.

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.

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?

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.

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


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. I am hoping that
by the time need arises, the compilers would have improved.

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

 

[loufoque]

Sachin Garg wrote :

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?

The GNU project (GNU/Linux, various libraries, ...) is mostly in C.
That may be the reason.

 

[Phlip]

I want my code to be usable on as wide variety of platforms as
possible.

Why? How about you find 1 customer, and target only _their_ platform, before
achieving delusions of godhood?

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.

Examine the Makefile systems (which are off-topic) for any of the popular
C++ mega libraries, such as Boost or ACE.

Here's the checklist for ACE:

config-WinCE.h config-psos-diab-mips.h
config-aix-4.1.x.h config-psos-diab-ppc.h
config-aix-4.2.x.h config-psos-diab.h
config-aix-4.3.x.h config-psos-tm.h
config-aix-4.x.h config-psosim-g++.h
config-aix-5.x.h config-qnx-neutrino.h
config-all.h config-qnx-rtp-62x.h
config-borland-common.h config-qnx-rtp-common.h
config-chorus.h config-qnx-rtp-pre62x.h
config-cray.h config-qnx-rtp.h
config-cxx-common.h config-rtems.h
config-cygwin32.h config-sco-4.2-nothread.h
config-dgux-4.11-epc.h config-sco-5.0.0-fsu-pthread.h
config-dgux-4.x-ghs.h config-sco-5.0.0-mit-pthread.h
config-doxygen.h config-sco-5.0.0-nothread.h
config-freebsd.h config-sco-5.0.0.h
config-fsu-pthread.h config-sunos4-g++.h
config-g++-common.h config-sunos4-lucid3.2.h
config-ghs-common.h config-sunos4-sun3.x.h
config-hpux-10.x-g++.h config-sunos4-sun4.1.4.h
config-hpux-10.x-hpc++.h config-sunos4-sun4.x.h
config-hpux-10.x.h config-sunos5.10.h
config-hpux-11.00.h config-sunos5.4-centerline-2.x.h
config-icc-common.h config-sunos5.4-g++.h
config-integritySCA.h config-sunos5.4-sunc++-4.x.h
config-irix5.2.h config-sunos5.5.h
config-irix5.3-g++.h config-sunos5.6.h
config-irix5.3-sgic++.h config-sunos5.7.h
config-irix6.5.x-sgic++.h config-sunos5.8.h
config-irix6.x-common.h config-sunos5.9.h
config-irix6.x-g++.h config-tandem-nsk-mips-v2.h
config-irix6.x-kcc.h config-tandem-nsk-mips-v3.h
config-irix6.x-sgic++-nothreads.h config-tandem.h
config-irix6.x-sgic++.h config-tru64.h
config-kcc-common.h config-unixware-2.01-g++.h
config-linux-common.h config-unixware-2.1.2-g++.h
config-linux.h config-unixware-7.1.0.h
config-lite.h config-unixware-7.1.0.udk.h
config-lynxos.h config-visualage.h
config-m88k.h config-vxworks5.x.h
config-macosx-panther.h config-vxworks6.2.h
config-macosx-tiger.h config-win32-borland.h
config-macosx.h config-win32-common.h
config-macros.h config-win32-dmc.h
config-minimal.h config-win32-ghs.h
config-mit-pthread.h config-win32-interix.h
config-mklinux.h config-win32-mingw.h
config-mvs.h config-win32-msvc-6.h
config-netbsd.h config-win32-msvc-7.h
config-openbsd.h config-win32-msvc-8.h
config-openvms.h config-win32-msvc.h
config-osf1-3.2.h config-win32-visualage.h
config-osf1-4.0.h config-win32.h
config-pharlap.h
config-posix.h

Note the list is long due to versions of platform and compiler after the OS
part. The first word after config- is the OS. Do you actually recognize
every OS on that list? I sure don't.

Do you have a working version of each of those OSs, to run your automated
tests on, before you deliver? Or were you thinking of promising the world's
OSF community that you support them, when all you did to support them was
pick C over C++?

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?

The systemic and popular open source projects are unfortunately in C. That's
because C has a wider base, and its Standard has been law for longer. Some
of those projects started before C++ had a standard, and some really do
target the OSs and embedded hardwares that don't support C++.

That still doesn't mean any code written in C is automatically portable. As
soon as you rely on a convenience like strdup(), you are beyond the
Standard, and must attend to endless platform specific issues. ACE and
Boost, being complete and popular systems written by thought-leaders, can
rely on an army of dweebs to maintain all their build systems.

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.

Right. So if you use C++, you will increase the odds that you _get_ enough
customers to need rabid portability.

 

[Jerry Coffin]

[ ... ]

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

This depends heavily on the kind of code you're writing.
If the code you're writing is suitable primarily for
truly tiny systems, C++ is likely to be a problem for
that code. If you're writing things that are suited
primarily for running on relatively capable systems, C++
probably won't be a problem -- and anymore, a capable
system includes not only desktop computers, but PDAs,
smart phones, etc.

At least for me, C++ is the clear choice unless you're
_quite_ certain that using it will lock you out of
virtually your entire target market.

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

I'd visit www.comeaucomputing.com if I were you.

 

[Phlip]

This depends heavily on the kind of code you're writing.
If the code you're writing is suitable primarily for
truly tiny systems, C++ is likely to be a problem for
that code.

Bloated libraries are likely to be a problem.

C++ makes writing feature-rich libraries easier than C.

Avoid C++'s feature-rich libraries.

Lean code should use polymorphism and generics to _remain_ lean.

Hence, use C++.

 

[Jerry Coffin]

Bloated libraries are likely to be a problem.

C++ makes writing feature-rich libraries easier than C.

Avoid C++'s feature-rich libraries.

Lean code should use polymorphism and generics to _remain_ lean.

Hence, use C++.

Unfortunately that doesn't fit with my experience. C++
includes exception handling, and at least with every
compiler I've seen yet, exception handling leads directly
to large code, more or less regardless of library usage.

Many (perhaps most) C++ compilers allow you to disable
generating code to support exception handling. The result
isn't really C++ anymore, but quite a few of us used a
language like that for quite a while, and found it quite
useful anyway. You do have to restrict your usage of the
language somewhat though, such as ensuring that nothing
you do in a ctor can fail, because you have no good way
to report such a failure.

I probably should have mentioned Embedded C++ as well. A
number of vendors got together and defined a subset of
C++ intended to target smaller embedded systems. There's
a fair amount of disagreement over how useful an exercise
this really was (Googling in this group should show a
number of related threads). Regardless of whether all the
decisions they made were fully justified, there are
apparently people who find it useful.

 

[Carlo Milanesi]

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?

False. It used to be so, but in recent years new open source projects
use C++ more often than C.
For instance, of the 73916 open source projects in SourceForge.net,
17468 use C++, and 16187 use C (many choices possible).
Famous open source applications written in C++ include eMule,
OpenOffice.org, QT, KDE, Mozilla/Firefox.

 

[Sachin Garg]

Unfortunately that doesn't fit with my experience. C++
includes exception handling, and at least with every
compiler I've seen yet, exception handling leads directly
to large code, more or less regardless of library usage.

Many (perhaps most) C++ compilers allow you to disable
generating code to support exception handling. The result
isn't really C++ anymore, but quite a few of us used a
language like that for quite a while, and found it quite
useful anyway. You do have to restrict your usage of the
language somewhat though, such as ensuring that nothing
you do in a ctor can fail, because you have no good way
to report such a failure.

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

I probably should have mentioned Embedded C++ as well. A
number of vendors got together and defined a subset of
C++ intended to target smaller embedded systems. There's
a fair amount of disagreement over how useful an exercise
this really was (Googling in this group should show a
number of related threads). Regardless of whether all the
decisions they made were fully justified, there are
apparently people who find it useful.

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.

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

 

[Sachin Garg]

[ ... ]

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

This depends heavily on the kind of code you're writing.
If the code you're writing is suitable primarily for
truly tiny systems, C++ is likely to be a problem for
that code. If you're writing things that are suited
primarily for running on relatively capable systems, C++
probably won't be a problem -- and anymore, a capable
system includes not only desktop computers, but PDAs,
smart phones, etc.

At least for me, C++ is the clear choice unless you're
_quite_ certain that using it will lock you out of
virtually your entire target market.

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

I'd visit www.comeaucomputing.com if I were you.

I landed here almost immediatly after I posted my original message.
This seems impressive. Anyone knows how good they are with templates?
MSVC 6.0 (with latest service packs) fails to understand my heavily
templated code, later versions work fine. Will they be able to handle
it?

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

 

[Chris Hills]

I know that language choices are more of a religious choice, rather
than a logical decision for many of us.

Unfortunately true... One poster here says

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...

A good SW engineer will know several languages and use the most
appropriate.

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.

This is correct.

Also in a lot of cases a C program will be more compact and faster than
the equivalent C++ program. Though if you are experienced with C++ and
the right compilers are available this difference can be mitigated I
believe.

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.

What does your code do? I doubt it will want to target 8, 16, 32, 64 and
128 bit machines?

C++ is not really available on 8 bit systems (over 30% of ALL MCU in the
world are 8 bit systems). where it is it is some what restricted.

On 16 bit systems EC++ tends to be used . AFAIK EC++ does not use
exceptions and the like.

So really you are looking at 32 and 64 Bit systems if you want to use
C++ On the other hand if 90% of your customers use 32 & 64 bit systems
what is the problem.

I can't imagine what SW you might produce that would be of use across
such a wide range of processors.

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.

I would only recommend C if a lot of your potential customers are in the
8 and 16 bit areas. Otherwise stay with C++ if it is what you are happy
with.

Especially as C is NOT a subset of C++....

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. I am hoping that
by the time need arises, the compilers would have improved.

Definitely. IF you get a big enough market I would think of doing a C
version for the 8/16 bit market and the C++ for the 32, 64 and 128
markets.

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?

Yes.... http://www.comeaucomputing.com/

 

[Andre Kostur]

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.

Probably results in too much code bloat. So they may have no additional
CPU impact, but may have a significantly increased memory footprint.

 

[Jerry Coffin]

[ ... ]

I landed here almost immediatly after I posted my original message.
This seems impressive. Anyone knows how good they are with templates?
MSVC 6.0 (with latest service packs) fails to understand my heavily
templated code, later versions work fine. Will they be able to handle
it?

Comeau's compiler is _extremely_ good with templates
(e.g. it supports export, which nearly nothing else
does). In fact, it's generally regarded as having the
best conformance available.

 

[Jerry Coffin]

[ Embedded C++ ]

I dont understand why they eliminated templates and namespaces. IMHO
these are just compile time tools which have no run-time overhead.

I believe your guess (mostly that they were new at the
time) is probably pretty close about namespaces. The
claimed reasoning about templates was that they could
lead to increases in code size because each instantiation
of a template results in a separate piece of code.

To a large extent, smarter linkers have cured that --
they're smart enough to recognize and merge identical
pieces of code.

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.

Personally, I think there were probably better places to
draw some of the lines between what would and wouldn't be
supported, but such is life. They would undoubtedly think
their choices are better than some I'd have made...

 

[Ian Collins]

I landed here almost immediatly after I posted my original message.
This seems impressive. Anyone knows how good they are with templates?
MSVC 6.0 (with latest service packs) fails to understand my heavily
templated code, later versions work fine. Will they be able to handle
it?

Just about any current (which MSVC 6.0 certainly isn't) compiler should
be "good they are with templates".

 

[Ian Collins]

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

Depends on your overhead, you might be happy to accept a bigger code
footprint for cleaner code and run time performance benefits.

 

[Sachin Garg]

Unfortunately true... One poster here says




A good SW engineer will know several languages and use the most
appropriate.



This is correct.

Also in a lot of cases a C program will be more compact and faster than
the equivalent C++ program. Though if you are experienced with C++ and
the right compilers are available this difference can be mitigated I
believe.


What does your code do? I doubt it will want to target 8, 16, 32, 64 and
128 bit machines?

C++ is not really available on 8 bit systems (over 30% of ALL MCU in the
world are 8 bit systems). where it is it is some what restricted.

On 16 bit systems EC++ tends to be used . AFAIK EC++ does not use
exceptions and the like.

So really you are looking at 32 and 64 Bit systems if you want to use
C++ On the other hand if 90% of your customers use 32 & 64 bit systems
what is the problem.

I can't imagine what SW you might produce that would be of use across
such a wide range of processors.


I would only recommend C if a lot of your potential customers are in the
8 and 16 bit areas. Otherwise stay with C++ if it is what you are happy
with.

Especially as C is NOT a subset of C++....


Definitely. IF you get a big enough market I would think of doing a C
version for the 8/16 bit market and the C++ for the 32, 64 and 128
markets.


Yes.... http://www.comeaucomputing.com/

I guess I will stick with C++ for now and either translate manually to
C or pick comeau when need arises (if need arises

Thanks everyone,

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

 

[Zara]

I guess I will stick with C++ for now and either translate manually to
C or pick comeau when need arises (if need arises

<...>


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*

Best regards,

Zara

 

[loufoque]

Sachin Garg wrote :

MSVC 6.0 (with latest service packs) fails to understand my heavily
templated code

Most so-called C++ compilers aren't fully standard conforming, but MSVC
6 is so old and broken that it really doesn't deserve to be called a C++
compiler.

 

[loufoque]

Carlo Milanesi wrote :

Famous open source applications written in C++ include eMule,
OpenOffice.org, QT, KDE, Mozilla/Firefox.

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

 

[loufoque]

Zara wrote :

I have to
write in a C++ dialect that is almost pre C++89 standrad

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