By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,417 Members | 1,845 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,417 IT Pros & Developers. It's quick & easy.

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

P: n/a
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 :-)

May 6 '06 #1
Share this Question
Share on Google+
34 Replies


P: n/a
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.
May 6 '06 #2

P: n/a
Sachin Garg wrote:
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.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
May 6 '06 #3

P: n/a
In article <1146912504.924340.136920
@u72g2000cwu.googlegroups.com>, sc*****@gmail.com says...

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

--
Later,
Jerry.

The universe is a figment of its own imagination.
May 6 '06 #4

P: n/a
Jerry Coffin wrote:
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++.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
May 6 '06 #5

P: n/a
In article <4Z37g.6053$mu2.757
@newssvr24.news.prodigy.net>, ph******@yahoo.com says...
Jerry Coffin wrote:
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++.


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.

--
Later,
Jerry.

The universe is a figment of its own imagination.
May 6 '06 #6

P: n/a
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?


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.

--
Carlo Milanesi
http://digilander.libero.it/carlmila
May 6 '06 #7

P: n/a

Jerry Coffin wrote:
In article <4Z37g.6053$mu2.757
@newssvr24.news.prodigy.net>, ph******@yahoo.com says...
Jerry Coffin wrote:
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++.


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

May 6 '06 #8

P: n/a

Jerry Coffin wrote:
In article <1146912504.924340.136920
@u72g2000cwu.googlegroups.com>, sc*****@gmail.com says...

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

May 6 '06 #9

P: n/a
In article <11**********************@u72g2000cwu.googlegroups .com>,
Sachin Garg <sc*****@gmail.com> writes
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/
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

May 6 '06 #10

P: n/a
In article <1146939445.235353.13300
@e56g2000cwe.googlegroups.com>, sc*****@gmail.com says...

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

--
Later,
Jerry.

The universe is a figment of its own imagination.
May 6 '06 #11

P: n/a
On Sat, 06 May 2006 11:14:28 -0700, Sachin Garg wrote:
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.
May 6 '06 #12

P: n/a
In article <1146939268.547436.316870
@i40g2000cwc.googlegroups.com>, sc*****@gmail.com says...

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

--
Later,
Jerry.

The universe is a figment of its own imagination.
May 6 '06 #13

P: n/a
Sachin Garg wrote:
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.
May 6 '06 #14

P: n/a
Sachin Garg wrote:
Jerry Coffin wrote:

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.

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

--
Ian Collins.
May 6 '06 #15

P: n/a

Chris Hills wrote:
In article <11**********************@u72g2000cwu.googlegroups .com>,
Sachin Garg <sc*****@gmail.com> writes
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/


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

May 7 '06 #16

P: n/a
On 7 May 2006 05:09:54 -0700, "Sachin Garg" <sc*****@gmail.com> wrote:

Chris Hills wrote:
In article <11**********************@u72g2000cwu.googlegroups .com>,
Sachin Garg <sc*****@gmail.com> writes
>I know that language choices are more of a religious choice, rather
>than a logical decision for many of us. <...> >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/


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
May 7 '06 #17

P: n/a
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.
May 7 '06 #18

P: n/a
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++.
May 7 '06 #19

P: n/a
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 ?

May 7 '06 #20

P: n/a
loufoque wrote:
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++.


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.

--
Carlo Milanesi
http://digilander.libero.it/carlmila
May 7 '06 #21

P: n/a
Sachin Garg wrote:

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
May 7 '06 #22

P: n/a
loufoque wrote:
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++.


What is 'modern' C++?

Ian
May 7 '06 #23

P: n/a
On Sun, 07 May 2006 15:17:28 +0200, loufoque
<lo******@remove.gmail.com> wrote:
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 ?


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
May 7 '06 #24

P: n/a
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.
May 8 '06 #25

P: n/a
In article <11**********************@u72g2000cwu.googlegroups .com>,
Sachin Garg <sc*****@gmail.com> wrote:
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?
--
Greg Comeau / Celebrating 20 years of Comeauity!
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
May 8 '06 #26

P: n/a
In article <11**********************@i40g2000cwc.googlegroups .com>,
Sachin Garg <sc*****@gmail.com> wrote:
Jerry Coffin wrote:
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 :-)


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


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.
--
Greg Comeau / Celebrating 20 years of Comeauity!
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
May 8 '06 #27

P: n/a
In article <11*********************@e56g2000cwe.googlegroups. com>,
Sachin Garg <sc*****@gmail.com> wrote:
Jerry Coffin wrote:
> Another thought (rather a wish ;-), are there any good/reliable
> translating compilers, which can translate my template and exception..

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?


Comeau C++ supports templates well. In many cases, it was the
first compiler to provide a template feature, including "clarifications"
found in C++03.
--
Greg Comeau / Celebrating 20 years of Comeauity!
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
May 8 '06 #28

P: n/a
On Sun, 07 May 2006 16:02:23 +0100 Ian Bell <ru*********@yahoo.co.uk>
waved a wand and this message magically appeared:
None of them, though, use modern C++.


What is 'modern' C++?


Were you the one who co-wrote Elite on the BBC B a long time ago (in
another galaxy?)

--
http://www.munted.org.uk

Take a nap, it saves lives.
May 8 '06 #29

P: n/a
In article <r3********************************@4ax.com>,
Zara <dl*******@dea.spamcon.org> wrote:
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.
--
Greg Comeau / Celebrating 20 years of Comeauity!
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
May 8 '06 #30

P: n/a
In article <44**********************@news.tiscali.it>,
Carlo Milanesi <ca********************@libero.it> wrote:
loufoque wrote:
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++.


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.
--
Greg Comeau / Celebrating 20 years of Comeauity!
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
May 8 '06 #31

P: n/a
In article <445e0d6e.0@entanet>, Ian Bell <ia*************@yahoo.co.uk> wrote:
Sachin Garg wrote:
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.


IOWs, in many cases not even Standard C is supported fully,
so why should C++ be? :)
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.


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


Also, how many _100% new_ OS projects are embedded related?
Most I'm aware of seem based on existing systems.
--
Greg Comeau / Celebrating 20 years of Comeauity!
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
May 8 '06 #32

P: n/a

Ian Collins wrote:
Sachin Garg wrote:
Jerry Coffin wrote:

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.

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


Agreed. There is always a "depends" :-)

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

May 10 '06 #33

P: n/a

Greg Comeau wrote:
In article <11*********************@e56g2000cwe.googlegroups. com>,
Sachin Garg <sc*****@gmail.com> wrote:
Jerry Coffin wrote:
> Another thought (rather a wish ;-), are there any good/reliable
> translating compilers, which can translate my template and exception..
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?


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


Thatz comforting :-)

Is there any demo/trial besides the web form?

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

May 10 '06 #34

P: n/a

Zara wrote:
On 7 May 2006 05:09:54 -0700, "Sachin Garg" <sc*****@gmail.com> wrote:

Chris Hills wrote:
In article <11**********************@u72g2000cwu.googlegroups .com>,
Sachin Garg <sc*****@gmail.com> writes
>I know that language choices are more of a religious choice, rather
>than a logical decision for many of us. <...> >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/


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*


"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

May 10 '06 #35

This discussion thread is closed

Replies have been disabled for this discussion.