C or C++ for embedded system plug-in?

Discussion in 'C++' started by Baron Samedi, Jan 3, 2007.

  1. Baron Samedi

    Baron Samedi Guest

    I want to produce a piece of software for embedded systems, generally
    telecoms based, mostly running on ARM processors, but I can't guarantee
    that, of course.

    My software should work along with other software which will generally
    be written in C or C++ (occasionally in ADA or even assembler).

    I suppose that there are C compilers for marginally more processors
    than C++, but, realistically, I am not sure that it makes a major
    difference.

    I suppose that C produces slightly smaller and faster code, but wonder
    if it makes a major difference.

    I like C++ exception handling (but know 6that it adds an overhead). I
    have clearly defined interfaces and interfacing software would gain
    nothing really by instantiating any classes, if I used C++

    I want to genericize functionality which the host software ought to
    provide, so that I can use their memory allocation routines, timers,
    debug tracing, etc, etc - probably just by offering some #defines,
    which they can change in a single header file, as necessary - but any
    advice is welcome.

    I think that I am leaning towards C, but am open to input ...

    Thanks in advance for any help.
     
    Baron Samedi, Jan 3, 2007
    #1
    1. Advertising

  2. Baron Samedi wrote:

    > I want to produce a piece of software for embedded systems, generally
    > telecoms based, mostly running on ARM processors, but I can't guarantee
    > that, of course.
    > My software should work along with other software which will generally
    > be written in C or C++ (occasionally in ADA or even assembler).


    In the majority of cases you just need a way to provide functions with C
    linkage and calling conventions, to be able to call him from another
    languages. Most language implementations provide ways to do that, then you
    can choose what language to use based in other requirements or preferences.

    --
    Salu2
     
    =?ISO-8859-15?Q?Juli=E1n?= Albo, Jan 3, 2007
    #2
    1. Advertising

  3. Baron Samedi

    bjeremy Guest

    Baron Samedi wrote:
    > I want to produce a piece of software for embedded systems, generally
    > telecoms based, mostly running on ARM processors, but I can't guarantee
    > that, of course.
    >
    > My software should work along with other software which will generally
    > be written in C or C++ (occasionally in ADA or even assembler).
    >
    > I suppose that there are C compilers for marginally more processors
    > than C++, but, realistically, I am not sure that it makes a major
    > difference.
    >
    > I suppose that C produces slightly smaller and faster code, but wonder
    > if it makes a major difference.
    >
    > I like C++ exception handling (but know 6that it adds an overhead). I
    > have clearly defined interfaces and interfacing software would gain
    > nothing really by instantiating any classes, if I used C++
    >
    > I want to genericize functionality which the host software ought to
    > provide, so that I can use their memory allocation routines, timers,
    > debug tracing, etc, etc - probably just by offering some #defines,
    > which they can change in a single header file, as necessary - but any
    > advice is welcome.
    >
    > I think that I am leaning towards C, but am open to input ...
    >
    > Thanks in advance for any help.


    I work on embedded systems for a large networking company. I work in
    the packet core on UMTS & GPRS GSN nodes. Our various GSN nodes differ
    in implementation our SGSN was written in C++ (however the compiler is
    very old and some of the features were disabled for whatever reason)
    and our GGSN was written in C, mainly since we inherited a lot of base
    routing, service and subscriber managment code written in C. Although I
    like working on our GGSN, mostly for the IP Service development, I urge
    you... if you are starting a project and have a choice.. use C++.... no
    matter how good your intentions are, using C is a maintainence
    nightmare. Not to mention extensibility and code reuse will suffer
    dramatically depending on the size of your project. Some code may still
    be needed to be written in Assembly or C (i.e. any special hardware
    like a fast ethernet line card would probably still need to be
    programmed in assembly for performance reasons).

    As for performance in C compared with C++, what I mainly seen are the
    capacity issues deal more with the design of the system. And C++
    provides less rope to hang yourself with than C.
     
    bjeremy, Jan 3, 2007
    #3
  4. Baron Samedi

    Baron Samedi Guest

    bjeremy wrote:
    > Baron Samedi wrote:
    > > I want to produce a piece of software for embedded systems, generally
    > > telecoms based, mostly running on ARM processors, but I can't guarantee
    > > that, of course.
    > >
    > > My software should work along with other software which will generally
    > > be written in C or C++ (occasionally in ADA or even assembler).
    > >
    > > I suppose that there are C compilers for marginally more processors
    > > than C++, but, realistically, I am not sure that it makes a major
    > > difference.
    > >
    > > I suppose that C produces slightly smaller and faster code, but wonder
    > > if it makes a major difference.
    > >
    > > I like C++ exception handling (but know 6that it adds an overhead). I
    > > have clearly defined interfaces and interfacing software would gain
    > > nothing really by instantiating any classes, if I used C++
    > >
    > > I want to genericize functionality which the host software ought to
    > > provide, so that I can use their memory allocation routines, timers,
    > > debug tracing, etc, etc - probably just by offering some #defines,
    > > which they can change in a single header file, as necessary - but any
    > > advice is welcome.
    > >
    > > I think that I am leaning towards C, but am open to input ...
    > >
    > > Thanks in advance for any help.

    >
    > I work on embedded systems for a large networking company. I work in
    > the packet core on UMTS & GPRS GSN nodes. Our various GSN nodes differ
    > in implementation our SGSN was written in C++ (however the compiler is
    > very old and some of the features were disabled for whatever reason)
    > and our GGSN was written in C, mainly since we inherited a lot of base
    > routing, service and subscriber managment code written in C. Although I
    > like working on our GGSN, mostly for the IP Service development, I urge
    > you... if you are starting a project and have a choice.. use C++.... no
    > matter how good your intentions are, using C is a maintainence
    > nightmare. Not to mention extensibility and code reuse will suffer
    > dramatically depending on the size of your project. Some code may still
    > be needed to be written in Assembly or C (i.e. any special hardware
    > like a fast ethernet line card would probably still need to be
    > programmed in assembly for performance reasons).
    >
    > As for performance in C compared with C++, what I mainly seen are the
    > capacity issues deal more with the design of the system. And C++
    > provides less rope to hang yourself with than C.



    Thanks for the great reply (and quick too).

    Basically, I want to have a common adaptation layer for
    handsets/modems/terminal adapters which sits above the protocol stack
    (AS/NAS, Layers 1 to 3) and offers a 24.007 interface at one side and a
    generic interface to different device drivers (USB, Ethernet, etc),
    probably appearing as a virtual serial port.

    The code probably won't be extensible by the end user, and I don't see
    them instantiating any objects, but I do like C++.

    As I stated, there will be fixed interfaces on both sides, one defined
    by CCITT/ETSI/3GPP and the other abstracting device drivers, so
    probably Virtual Serial Port. Users only get to tweak a few macros to
    determine how my software allocates memory, performs debug tracing,
    handles timers and the like.

    You have certainly given me food for thought. Thanks.
     
    Baron Samedi, Jan 3, 2007
    #4
  5. "bjeremy" <> wrote in message
    news:...
    > As for performance in C compared with C++, what I mainly seen are the
    > capacity issues deal more with the design of the system. And C++
    > provides less rope to hang yourself with than C.


    In your opinion of course. In MY opinion C++ provides all the rope you can
    hang yourself with as in C plus a whole lot extra. But you shouldnt worry
    about that at all if you have competent programmers. C and C++ are both
    great languages that get the job done from the lowest level to the highest.
    If I had the choice of language for a next project I would choose what I
    like best and not ask advice from biased newsgroup people
     
    Serve Laurijssen, Jan 3, 2007
    #5
  6. Serve Laurijssen a écrit :
    > "bjeremy" <> wrote in message
    > news:...
    >> As for performance in C compared with C++, what I mainly seen are the
    >> capacity issues deal more with the design of the system. And C++
    >> provides less rope to hang yourself with than C.

    >
    > In your opinion of course. In MY opinion C++ provides all the rope you can
    > hang yourself with as in C plus a whole lot extra. But you shouldnt worry
    > about that at all if you have competent programmers. C and C++ are both
    > great languages that get the job done from the lowest level to the highest.
    > If I had the choice of language for a next project I would choose what I
    > like best and not ask advice from biased newsgroup people
    >
    >


    In truth, I have seen many good C programmers wanting to hang themselves
    when they learned they would have to code in C++ :)

    For further reading, you can try this article:
    http://www.ganssle.com/articles/alingo.htm

    Michael
     
    Michael DOUBEZ, Jan 3, 2007
    #6
  7. Baron Samedi

    CBFalconer Guest

    Serve Laurijssen wrote:
    > "bjeremy" <> wrote in message
    >
    >> As for performance in C compared with C++, what I mainly seen
    >> are the capacity issues deal more with the design of the system.
    >> And C++ provides less rope to hang yourself with than C.

    >
    > In your opinion of course. In MY opinion C++ provides all the rope
    > you can hang yourself with as in C plus a whole lot extra. But you
    > shouldnt worry about that at all if you have competent programmers.
    > C and C++ are both great languages that get the job done from the
    > lowest level to the highest. If I had the choice of language for a
    > next project I would choose what I like best and not ask advice
    > from biased newsgroup people


    If you want a widely available language and maximum safety use Ada.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>
     
    CBFalconer, Jan 3, 2007
    #7
  8. Baron Samedi

    Al Balmer Guest

    On 2 Jan 2007 18:14:32 -0800, "bjeremy" <> wrote:

    > no
    >matter how good your intentions are, using C is a maintainence
    >nightmare. Not to mention extensibility and code reuse will suffer
    >dramatically depending on the size of your project.


    I have a different opinion. If you have the stated problems with C,
    they are due more to your programmers than the language. C can be
    written to be easily maintainable, extensible, and reusable. In fact,
    I've seen many cases where the initial partitioning of the problem and
    resulting choice of classes made C++ code much more of a problem in
    maintenance, extensibility, and reuse.

    C++ which takes advantage of OO techniques often ends up "all of a
    piece", and disturbing one portion perturbs everything else. It's
    possible to design programs using classes which are nicely extensible
    and reusable, but it's difficult and time consuming, and all too
    seldom done properly.

    --
    Al Balmer
    Sun City, AZ
     
    Al Balmer, Jan 3, 2007
    #8
  9. Baron Samedi

    jacob navia Guest

    Al Balmer a écrit :
    > C++ which takes advantage of OO techniques often ends up "all of a
    > piece", and disturbing one portion perturbs everything else.


    Specially if everything is done in constructors, making it
    very difficult to take out one part of that code...
     
    jacob navia, Jan 3, 2007
    #9
  10. Baron Samedi

    Ian Collins Guest

    Al Balmer wrote:
    > On 2 Jan 2007 18:14:32 -0800, "bjeremy" <> wrote:
    >
    >>no matter how good your intentions are, using C is a maintainence
    >>nightmare. Not to mention extensibility and code reuse will suffer
    >>dramatically depending on the size of your project.

    >
    >
    > I have a different opinion. If you have the stated problems with C,
    > they are due more to your programmers than the language.


    Programmers or process.

    > C can be
    > written to be easily maintainable, extensible, and reusable.


    As can any language, even assembly.

    > In fact,
    > I've seen many cases where the initial partitioning of the problem and
    > resulting choice of classes made C++ code much more of a problem in
    > maintenance, extensibility, and reuse.
    >

    That's one reason why BDUF is a mistake.

    > C++ which takes advantage of OO techniques often ends up "all of a
    > piece", and disturbing one portion perturbs everything else. It's
    > possible to design programs using classes which are nicely extensible
    > and reusable, but it's difficult and time consuming, and all too
    > seldom done properly.
    >

    I agree, that's why OO designs (in any language) should evolve rather
    that be done up front.

    --
    Ian Collins.
     
    Ian Collins, Jan 3, 2007
    #10
  11. Baron Samedi

    bjeremy Guest

    Serve Laurijssen wrote:
    > "bjeremy" <> wrote in message
    > news:...
    > > As for performance in C compared with C++, what I mainly seen are the
    > > capacity issues deal more with the design of the system. And C++
    > > provides less rope to hang yourself with than C.

    >
    > In your opinion of course. In MY opinion C++ provides all the rope you can
    > hang yourself with as in C plus a whole lot extra. But you shouldnt worry
    > about that at all if you have competent programmers. C and C++ are both
    > great languages that get the job done from the lowest level to the highest.
    > If I had the choice of language for a next project I would choose what I
    > like best and not ask advice from biased newsgroup people


    This is probably not the case for the OP... but as to the above comment
    the relevent term here is "competent programmers". A lot of shops do a
    significant amount of outsourcing which has a number of problems. One
    of them is *NOT* that there are no competent contractors in India,
    Vietname, China, or other countries, the problem is that most companies
    will not pay for them. I've seen them again and again try and get the
    contractors for the lowest pay they can. This does not draw top talent.
    (i.e. While Infosys has a lot of IIT grads, I have only worked with
    one, of course he was very capable.)

    This also creates an attrition effect. As more and more contractors who
    work on your project become competent, they will leave for a more
    lucrative offer. This all but guarantees that you will have a fresh
    stream of "new hires" working on your system every 3 to 6 months.

    I have also noticed a significant portion of the development cycle lost
    due to communications between Designers on two sides of the globe
    communicating mainly through email. Since we are usually 11 or more
    hours appart it usually takes days to resolve a problem.

    In an environment such as this (And I understand this does not apply to
    all shops), I would have to say IMO ***maintainability of the existing
    software is paramount to all else***. Easily understandable code makes
    for less ramp up time, and it seems fewer software bugs introduced
    during bug fixes and and/or redesign of existing systems, and it also
    creates a more autonomous working evironment where communication, while
    still necessary, is limited and less likely to cause delays.
     
    bjeremy, Jan 3, 2007
    #11
  12. Baron Samedi

    Grizlyk Guest

    Al Balmer wrote:
    >>
    >>bjeremy wrote:
    >>no matter how good your intentions are, using C is a maintainence
    >>nightmare. Not to mention extensibility and code reuse will suffer
    >>dramatically depending on the size of your project.

    >
    > I have a different opinion. If you have the stated problems with C,
    > they are due more to your programmers than the language. C can be
    > written to be easily maintainable, extensible, and reusable. In fact,
    > I've seen many cases where the initial partitioning of the problem and
    > resulting choice of classes made C++ code much more of a problem in
    > maintenance, extensibility, and reuse.


    I think, if you are not using OO design, C++ is generaly equal to C.

    But in addition, for C++ you can use classes as ATD (abstract data
    types) created by composition (without inheritance, design patterns and
    so on). In other words, you can use classes as impoved C modules and
    types. You can also use C++ overloading for functions.

    C can be more compatible than C++ for cross-platforms works due to more
    limited C features and more simple rules, that can be easy understanded
    by programmer without confusions. (The most simple rules is ASM (mov
    ax,bx), but hundreads of lines of asm is absolutely unreadable).
     
    Grizlyk, Jan 4, 2007
    #12
  13. Baron Samedi

    Baron Samedi Guest

    Serve Laurijssen wrote:
    > "bjeremy" <> wrote in message
    > news:...
    > > As for performance in C compared with C++, what I mainly seen are the
    > > capacity issues deal more with the design of the system. And C++
    > > provides less rope to hang yourself with than C.

    >
    > In your opinion of course. In MY opinion C++ provides all the rope you can
    > hang yourself with as in C plus a whole lot extra. But you shouldnt worry
    > about that at all if you have competent programmers. C and C++ are both
    > great languages that get the job done from the lowest level to the highest.
    > If I had the choice of language for a next project I would choose what I
    > like best and not ask advice from biased newsgroup people


    A valid point, but I am happy with both. I will admit that most of my
    professional work (telecomms) is C, and most of my hobby programming is
    C++ (windows programs with GUIS0, so I have some - but not too much -
    experience of C++ in embedded systems. That's why I asked. I was
    interested in what others have thought.

    To be honest, I am not too hung up on programming language. When
    recruiting, I always consider telecoms experience as the prime
    importance. FRO C projects, I don't care about language experience ;
    for C++, I prefer some C++, or other OO.

    A few years ago I worked for a company which was fixated on ADA. They
    recruited a whole team to do a protocol stack. None of us had any ADA
    experience, but we turned out a good product.
     
    Baron Samedi, Jan 4, 2007
    #13
  14. Baron Samedi

    CBFalconer Guest

    Baron Samedi wrote:
    >

    .... snip ...
    >
    > A few years ago I worked for a company which was fixated on ADA.
    > They recruited a whole team to do a protocol stack. None of us
    > had any ADA experience, but we turned out a good product.


    Which says something about the reliability of Ada.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>
     
    CBFalconer, Jan 4, 2007
    #14
  15. Baron Samedi

    Chris Hills Guest

    In article <>,
    Baron Samedi <> writes
    >I want to produce a piece of software for embedded systems, generally
    >telecoms based, mostly running on ARM processors, but I can't guarantee
    >that, of course.


    Then try comp.arch.embedded they understand embedded systems and
    hardware.

    >
    >My software should work along with other software which will generally
    >be written in C or C++ (occasionally in ADA or even assembler).
    >
    >I suppose that there are C compilers for marginally more processors
    >than C++, but, realistically, I am not sure that it makes a major
    >difference.


    There are a LOT more C than C++ compilers. Especially for the smaller
    micros. Also I think you will find it is easier to interface the other
    languages to C than C++

    >I suppose that C produces slightly smaller and faster code, but wonder
    >if it makes a major difference.


    Depends on your compiler(s) and target platform. It might make a major
    difference but then again it may not.

    >I like C++ exception handling (but know 6that it adds an overhead). I
    >have clearly defined interfaces and interfacing software would gain
    >nothing really by instantiating any classes, if I used C++


    These may not be supported by all C++ compilers fro embedded targets.


    --
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
    \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
    /\/\/ www.phaedsys.org \/\/\
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
     
    Chris Hills, Jan 4, 2007
    #15
  16. Baron Samedi

    Chris Hills Guest

    In article <>, CBFalconer
    <> writes
    >Serve Laurijssen wrote:
    >> "bjeremy" <> wrote in message
    >>
    >>> As for performance in C compared with C++, what I mainly seen
    >>> are the capacity issues deal more with the design of the system.
    >>> And C++ provides less rope to hang yourself with than C.

    >>
    >> In your opinion of course. In MY opinion C++ provides all the rope
    >> you can hang yourself with as in C plus a whole lot extra. But you
    >> shouldnt worry about that at all if you have competent programmers.
    >> C and C++ are both great languages that get the job done from the
    >> lowest level to the highest. If I had the choice of language for a
    >> next project I would choose what I like best and not ask advice
    >> from biased newsgroup people

    >
    >If you want a widely available language and maximum safety use Ada.


    Compared to C ADA is not widely available or supported.

    As for Maximum safety... you can make a mess in Ada just as much as any
    other language. For maximum safety you could use SPARK but that is
    even less available.

    BTW which language did they choose for the US Joint Strike Fighter?
    (Do you know why? )

    --
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
    \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
    /\/\/ www.phaedsys.org \/\/\
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
     
    Chris Hills, Jan 4, 2007
    #16
  17. Baron Samedi

    Chris Hills Guest

    In article <>, CBFalconer
    <> writes
    >Baron Samedi wrote:
    >>

    >... snip ...
    >>
    >> A few years ago I worked for a company which was fixated on ADA.
    >> They recruited a whole team to do a protocol stack. None of us
    >> had any ADA experience, but we turned out a good product.

    >
    >Which says something about the reliability of Ada.
    >

    It doesn't say anything about Ada... They might have been just as
    successful in Mod2, Pascal, Chill, Fortran etc

    It does say something about the team though.

    --
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
    \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
    /\/\/ www.phaedsys.org \/\/\
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
     
    Chris Hills, Jan 4, 2007
    #17
  18. Baron Samedi

    Henryk Guest

    We made very good experience with C++ on embedded systems even for time
    critical tasks.

    For our system we restricted the C++ features that are allowed. Those
    are:
    - no dynamic memory allocation (no new, delete, malloc, free etc.)
    - no exceptions
    - no run time type information
    - no virtual functions
    - no templates

    Some of the restrictions were due to the first platform we used
    (compiler did not support templates) others were choosen to increase
    robustness and speed.

    The resulting software is very modular and and code is easy to read. We
    almost never had any of those typical C memory access errors...

    The great benefits of C++ over C in this projects are:
    - excessive usage of references instead of pointers makes the code very
    robust
    - excessive usage of const classifiers avoids mis-usage of objects
    - class access rights + lightweight inline methods (set, get) assure
    protection of internal module variables. Old projects were full of
    those evil extern declarations...
    - constructors assure proper initialized modules
    - all of those features above come with virtual no runtime overhead.

    One of the disadvantage of C++ is a slightly greater memory footprint
    because C++ environment initialization is more sophisticated...

    I really like the beauty of our lightwight wrappers for hardware
    interfaces. Almost no runtime-overhead, intuitive usage, and very
    robust against abuse at the same time. Much better than anything that
    you can achieve in C.

    Our experience with C++ on embedded systems were so good that we use C
    only for those platform that does not provide a proper C++ compiler.

    Henryk
     
    Henryk, Jan 4, 2007
    #18
  19. Baron Samedi

    Henryk Guest

    We made very good experience with C++ on embedded systems even for time
    critical tasks.

    For our system we restricted the C++ features that are allowed. Those
    are:
    - no dynamic memory allocation (no new, delete, malloc, free etc.)
    - no exceptions
    - no run time type information
    - no virtual functions
    - no templates

    Some of the restrictions were due to the first platform we used
    (compiler did not support templates) others were choosen to increase
    robustness and speed.

    The resulting software is very modular and and code is easy to read. We
    almost never had any of those typical C memory access errors...

    The great benefits of C++ over C in this projects are:
    - excessive usage of references instead of pointers makes the code very
    robust
    - excessive usage of const classifiers avoids mis-usage of objects
    - class access rights + lightweight inline methods (set, get) assure
    protection of internal module variables. Old projects were full of
    those evil extern declarations...
    - constructors assure proper initialized modules
    - all of those features above come with virtual no runtime overhead.

    One of the disadvantage of C++ is a slightly greater memory footprint
    because C++ environment initialization is more sophisticated...

    I really like the beauty of our lightwight wrappers for hardware
    interfaces. Almost no runtime-overhead, intuitive usage, and very
    robust against abuse at the same time. Much better than anything that
    you can achieve in C.

    Our experience with C++ on embedded systems were so good that we use C
    only for those platform that does not provide a proper C++ compiler.

    Henryk
     
    Henryk, Jan 4, 2007
    #19
  20. Baron Samedi

    Henryk Guest

    We made very good experience with C++ on embedded systems even for time
    critical tasks.

    For our system we restricted the C++ features that are allowed. Those
    are:
    - no dynamic memory allocation (no new, delete, malloc, free etc.)
    - no exceptions
    - no run time type information
    - no virtual functions
    - no templates

    Some of the restrictions were due to the first platform we used
    (compiler did not support templates) others were choosen to increase
    robustness and speed.

    The resulting software is very modular and and code is easy to read. We
    almost never had any of those typical C memory access errors...

    The great benefits of C++ over C in this projects are:
    - excessive usage of references instead of pointers makes the code very
    robust
    - excessive usage of const classifiers avoids mis-usage of objects
    - class access rights + lightweight inline methods (set, get) assure
    protection of internal module variables. Old projects were full of
    those evil extern declarations...
    - constructors assure proper initialized modules
    - all of those features above come with virtual no runtime overhead.

    One of the disadvantage of C++ is a slightly greater memory footprint
    because C++ environment initialization is more sophisticated...

    I really like the beauty of our lightwight wrappers for hardware
    interfaces. Almost no runtime-overhead, intuitive usage, and very
    robust against abuse at the same time. Much better than anything that
    you can achieve in C.

    Our experience with C++ on embedded systems were so good that we use C
    only for those platform that does not provide a proper C++ compiler.

    Henryk
     
    Henryk, Jan 4, 2007
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Colin Paul Gloster
    Replies:
    48
    Views:
    1,892
    Colin Paul Gloster
    Apr 10, 2007
  2. Baron Samedi

    C or C++ for embedded system plug-in?

    Baron Samedi, Jan 3, 2007, in forum: C Programming
    Replies:
    42
    Views:
    929
    Lionel B
    Jan 10, 2007
  3. Thomas Dodds

    Databind an embedded control in an embedded datagrid

    Thomas Dodds, Jul 26, 2004, in forum: ASP .Net Datagrid Control
    Replies:
    0
    Views:
    402
    Thomas Dodds
    Jul 26, 2004
  4. George Maney
    Replies:
    1
    Views:
    284
    Lucien
    Jan 22, 2004
  5. Trans
    Replies:
    11
    Views:
    303
    micathom
    Sep 5, 2007
Loading...

Share This Page