prevalence of C++ in embedded linux?

prevalence of C++ in embedded linux?

[Robert P. J. Day]

  just curious -- how many folks are working in C++ in their embedded
linux work?

rday
--

========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
    Have classroom, will lecture.

http://crashcourse.ca                          Waterloo, Ontario, CANADA
========================================================================

Re: prevalence of C++ in embedded linux?

[Chris]

In my experience, > 50%, especially the larger projects such as set top 
boxes, printers, mobile devices...

Chris.

Robert P. J. Day wrote:
>   just curious -- how many folks are working in C++ in their embedded
> linux work?
> 
> rday
> --
> 
> ========================================================================
> Robert P. J. Day
> Linux Consulting, Training and Annoying Kernel Pedantry:
>     Have classroom, will lecture.
> 
> http://crashcourse.ca                          Waterloo, Ontario, CANADA
> ========================================================================
> --
> To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: prevalence of C++ in embedded linux?

[Jamie Lokier]

Robert P. J. Day wrote:
>   just curious -- how many folks are working in C++ in their embedded
> linux work?

I'm avoiding it, because of reports of occasional elf2flt relocation
errors when using C++ a few months ago, on this list.

However, some of the libraries I'm using have some C++ in them, and a
C API wrapped around the C++ core!  I'm glad they use a C wrapper, as
they only supply binaries build with GCC 2.95.3, I have the impression
the C++ ABI has changed between that and GCC 4.x.  But I haven't checked.

All systems using Qt (such as Qtopia) will use C++ a lot, so it is
well supported.

-- Jamie

Re: prevalence of C++ in embedded linux?

[Domenico Andreoli]

On Mon, Jul 28, 2008 at 11:43:17AM -0400, Robert P. J. Day wrote:
> 
>   just curious -- how many folks are working in C++ in their embedded
> linux work?

my app is mostly written in c++/boost. fat stuff on my not-so-embedded
set-top-box, but if I had to rewrite it in plain C _I_ would get
very fat... :)

cheers,
Domenico

-----[ Domenico Andreoli, aka cavok
 --[ http://www.dandreoli.com/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50

Re: prevalence of C++ in embedded linux?

[Matthias Kaehlcke]

El Mon, Jul 28, 2008 at 11:43:17AM -0400 Robert P. J. Day ha dit:

>   just curious -- how many folks are working in C++ in their embedded
> linux work?

i'm working on an embedded project in c++. until now the experience is
positive (i have a large background with c++ in non-embedded project),
probably new projects will also be done in c++.

-- 
Matthias Kaehlcke
Embedded Linux Engineer
Barcelona

               For to be free is not merely to cast off
               one's chains, but to live in a way that
              respects and enhances the freedom of others
                           (Nelson Mandela)
                                                                 .''`.
    using free software / Debian GNU/Linux | http://debian.org  : :'  :
                                                                `. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4                  `-

Re: prevalence of C++ in embedded linux?

[Ben Nizette]

On Mon, 2008-07-28 at 11:43 -0400, Robert P. J. Day wrote:
> just curious -- how many folks are working in C++ in their embedded
> linux work?

I hang out on AVRFreaks - an AVR and AVR32 support forum - quite a bit.
I personally think C++ is the language of the devil but I'd say that
around 50% of the people I talk to on 'freaks think otherwise.  It's
certainly the language of choice.

There's also a surprising number (~5%?) using Java on a small JVM (eg
JamVM) and about the same using Python.

Of course a largish number don't really need to write any code at all.
They just need to wire up existing programs to do what they want then
maybe glue a bit of PHP between that and the user so it doesn't /look/
like Linux from the outside.

	--Ben.  

> 
> rday
> --

Re: prevalence of C++ in embedded linux?

[Roberto A. Foglietta]

2008/7/28 Ben Nizette <bn@niasdigital.com>:
>
> On Mon, 2008-07-28 at 11:43 -0400, Robert P. J. Day wrote:
>> just curious -- how many folks are working in C++ in their embedded
>> linux work?
>

 [cut]

> Of course a largish number don't really need to write any code at all.
> They just need to wire up existing programs to do what they want then
> maybe glue a bit of PHP between that and the user so it doesn't /look/
> like Linux from the outside.
>

 Apart kernel space and its modules I use C and shell script for
gluing all togheter!
 In the last project I used 4423 lines of shell script as glue for C
applications.
 :-)

 Cheers,
-- 
/roberto
http://www.roberto.foglietta.name/work

Re: prevalence of C++ in embedded linux?

[Ben Nizette]

On Tue, 2008-07-29 at 07:47 +1000, Ben Nizette wrote:
> On Mon, 2008-07-28 at 11:43 -0400, Robert P. J. Day wrote:
> > just curious -- how many folks are working in C++ in their embedded
> > linux work?
> 
> I hang out on AVRFreaks - an AVR and AVR32 support forum - quite a bit.
> I personally think C++ is the language of the devil but I'd say that
> around 50% of the people I talk to on 'freaks think otherwise.  It's
> certainly the language of choice.

Having said that, I would appear to be quite wrong.  Of course, I only
see people's language of choice on a support forum when it doesn't work
as they'd like.  From those numbers I got the 50% figure.  A quick poll
[1] doesn't even almost agree, though admittedly the sample group isn't
huge yet.

Interesting.

	--Ben.

[1]
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=473243#473243

Re: prevalence of C++ in embedded linux?

[Marco Stornelli]

Robert P. J. Day ha scritto:
>   just curious -- how many folks are working in C++ in their embedded
> linux work?
> 
> rday
> --
> 
> ========================================================================
> Robert P. J. Day
> Linux Consulting, Training and Annoying Kernel Pedantry:
>     Have classroom, will lecture.
> 
> http://crashcourse.ca                          Waterloo, Ontario, CANADA
> ========================================================================
> --
> To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
Like Linus Torvals said "...C++ is an horrible language" :)

-- 
Marco Stornelli
Embedded Software Engineer
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
http://www.coritel.it

marco.stornelli@coritel.it
+39 06 72582838

Re: prevalence of C++ in embedded linux?

[Alexander Neundorf]

On Tuesday 29 July 2008 09:40:20 Marco Stornelli wrote:
> Robert P. J. Day ha scritto:
> >   just curious -- how many folks are working in C++ in their embedded
> > linux work?
> >
> > rday
> > --
> >
> > To unsubscribe from this list: send the line "unsubscribe linux-embedded"
> > in the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> Like Linus Torvals said "...C++ is an horrible language" :)

If you avoid RTTI and exceptions and if you are handle templates and multiple 
inheritance carefully I see nothing which speaks against using it for 
embedded and real-time software.
e.g. the kernel eCos is implemented in C++.

Alex

Re: prevalence of C++ in embedded linux?

[Bernd Petrovitsch]

On Tue, 2008-07-29 at 09:51 +0200, Alexander Neundorf wrote:
> On Tuesday 29 July 2008 09:40:20 Marco Stornelli wrote:
> > Robert P. J. Day ha scritto:
> > >   just curious -- how many folks are working in C++ in their embedded
> > > linux work?

Not if it's in anyway avoidable.

[....]
> > Like Linus Torvals said "...C++ is an horrible language" :)
> 
> If you avoid RTTI and exceptions and if you are handle templates and multiple 
> inheritance carefully I see nothing which speaks against using it for 
> embedded and real-time software.

That's the main reason for *not* using C++ in the embedded world in the
first place.
Tell people that they may use C++ and see them happy.
Then tell them that you better not use templates, RTTI, exceptions and
multiple inheritance if you want to boot from small space.

Yes, one *can* use the above features and get small features. But most
people simply can't - if only that they use some tool/lib written in C++
(and coming from the "normal" world) which simply uses them without
thinking about space and wonder why the device won't run with "only"
128MB flash and run in 16MB RAM.

BTW why should I use C++ if I don't use any "fancy features"?

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: prevalence of C++ in embedded linux?

[Marco Stornelli]

Bernd Petrovitsch ha scritto:
> On Tue, 2008-07-29 at 09:51 +0200, Alexander Neundorf wrote:
>> On Tuesday 29 July 2008 09:40:20 Marco Stornelli wrote:
>>> Robert P. J. Day ha scritto:
>>>>   just curious -- how many folks are working in C++ in their embedded
>>>> linux work?
> 
> Not if it's in anyway avoidable.
> 
> [....]
>>> Like Linus Torvals said "...C++ is an horrible language" :)
>> If you avoid RTTI and exceptions and if you are handle templates and multiple 
>> inheritance carefully I see nothing which speaks against using it for 
>> embedded and real-time software.
> 
> That's the main reason for *not* using C++ in the embedded world in the
> first place.
> Tell people that they may use C++ and see them happy.
> Then tell them that you better not use templates, RTTI, exceptions and
> multiple inheritance if you want to boot from small space.
> 
> Yes, one *can* use the above features and get small features. But most
> people simply can't - if only that they use some tool/lib written in C++
> (and coming from the "normal" world) which simply uses them without
> thinking about space and wonder why the device won't run with "only"
> 128MB flash and run in 16MB RAM.
> 
> BTW why should I use C++ if I don't use any "fancy features"?
> 
> 	Bernd
I quite agree with you

-- 
Marco Stornelli
Embedded Software Engineer
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
http://www.coritel.it

marco.stornelli@coritel.it
+39 06 72582838

Re: prevalence of C++ in embedded linux?

[Alexander Neundorf]

On Tuesday 29 July 2008 10:20:12 you wrote:
> On Tue, 2008-07-29 at 09:51 +0200, Alexander Neundorf wrote:
...
> Yes, one *can* use the above features and get small features. But most
> people simply can't - if only that they use some tool/lib written in C++
> (and coming from the "normal" world) which simply uses them without
> thinking about space and wonder why the device won't run with "only"
> 128MB flash and run in 16MB RAM.

Well, if somebody carelessly uses general purpose apps/libs in a tiny embedded 
project he will have problems, no matter if it's C or C++.

> BTW why should I use C++ if I don't use any "fancy features"?

If you just skip RTTI and exceptions you have enough fancy features left :-)

Just know what you're doing if you're using templates and multiple 
inheritance, there is no problem with them. Templates are so much better than 
macros, and if used carefully they don't bloat the code size.

Alex

Re: prevalence of C++ in embedded linux?

[Bernd Petrovitsch]

On Tue, 2008-07-29 at 10:58 +0200, Alexander Neundorf wrote:
> On Tuesday 29 July 2008 10:20:12 you wrote:
> > On Tue, 2008-07-29 at 09:51 +0200, Alexander Neundorf wrote:
> ...
> > Yes, one *can* use the above features and get small features. But most
> > people simply can't - if only that they use some tool/lib written in C++
> > (and coming from the "normal" world) which simply uses them without
> > thinking about space and wonder why the device won't run with "only"
> > 128MB flash and run in 16MB RAM.
> 
> Well, if somebody carelessly uses general purpose apps/libs in a tiny embedded 
> project he will have problems, no matter if it's C or C++.

Of course.
But it is IMHO much more easier and seductive to use the code bloating
features with C++ - especially if you don't know what to do and do not
realize (until it's too late).

Evey other potential customer asks about C++ on an embedded device. And
if you say "yes" they *expect* to use all that g++ allows. Period.

Getting exceptions and restrictions to the use of C++ (including any 3rd
party software - known and unknown) in an offer?
Please be serious.

Discussing afterwards that these templates are a very bad idea (and need
to be converted to "a pure virtual class and lots of classes" to avoid
code bloat and that it will cost a few man-weeks and calendar time)?
I can hear it already: "But you said that C++ is OK and this is plain C
++".

> > BTW why should I use C++ if I don't use any "fancy features"?
> 
> If you just skip RTTI and exceptions you have enough fancy features left :-)

Hmm, does g++ has options to completely disabled these (and other)
"fancy features"? At least one could check 3rd party software more
easily if they actually use that.

Multiple inheritance[0] is in my experience not really necessary (if
ever used).
I already have "Safe C" with gcc anyways (if I want and enable some
warnings;-).
OO design is a question of design and not of the implementation
language. I can't see much difference between
- declaring a class and using a method or
- declaring a struct and use a pointer to an instance as the first
   parameter in several functions.
Leaves operator/function overloading and default values for parameters.
But it adds usually libstdc++.so ....

> Just know what you're doing if you're using templates and multiple 

ACK. But what is with the other 90%?

> inheritance, there is no problem with them. Templates are so much better than 
> macros, and if used carefully they don't bloat the code size.

Don't get me wrong - I'm not religiously against C++ in anyway.
It's just that you *really* need to know what you do and that implies
IMHO for C++ that you must know how templates work/are implemented.
Similar for exceptions (and no, using exceptions usually doesn't save
space anywhere - at least not if your calling depth is < 100). if you
use them (or use a library that uses them).
And may need or may not need libstdc++.so - an additional piece of code
using space.
Of course, if you have 1GB of flash and 256M RAM, who cares. But most of
the devices I see are not that "fat".

In short: It is far from easy to *not* shoot yourself in the foot with
C++. At least compared to plain C.

	Bernd

[0]: Yes, I know what's the difference between normal and virtual
         inheritance.
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

RE: prevalence of C++ in embedded linux?

[Leisner, Martin]

If you're embedded device has a window system, than a language like C++
is fine...But...

To extend on this quote (by Stroustrup):  "In C++ it's harder to shoot
yourself in the foot, but when you do, you blow off your whole leg.".

I've found you can understand spaghetti C code with some effort -- its
nearly impossible to understand spaghetti C++ code.  Much professional
programming is "kitchen sink mentality" -- if there's a feature, use it.

I find it interesting K&R is about 200 pages, Stroustrup is 1000+ pages.
What percentage of the 200 pages is understood by the average C
programmer versus the 1000+ pages by the average C++ programmers?

I program by the quote by Einstein "Things should be as simple as
possible, no simpler".

Much of the C++ code I've seen has more complicated implementation
details than the problem being solved (I'm a believer in Halstead
metrics, a lot of solutions I've seen in C++ would be much smaller in
C).  Of course, that's the solutions in C++ I've seen...not all of
them....

I think C++ lends itself to coming up with complicated solutions to
simple problems...(of course really good C++ is simple and clever...but
much C++ I
see is poorly designed raw overcooked spaghetti).  

Also its very useful to have an understanding how the hardware works in
systems where memory/time is an issue (and it almost always should be an
issue).  I have a good understanding of what will happen in my C
compiler 
(a good algorithm in C runs rings around bad algorithms in assembler).
[nowadays, instead of processor performance, you think about cache
performance].  I doubt there's generally a good understand of time/space
of C++ features in the compiler and standard library...]

marty

>   -----Original Message-----
>   From: linux-embedded-owner@vger.kernel.org [mailto:linux-embedded-
>   owner@vger.kernel.org] On Behalf Of Bernd Petrovitsch
>   Sent: Tuesday, July 29, 2008 5:47 AM
>   To: Alexander Neundorf
>   Cc: linux-embedded@vger.kernel.org
>   Subject: Re: prevalence of C++ in embedded linux?
>   
>   On Tue, 2008-07-29 at 10:58 +0200, Alexander Neundorf wrote:
>   > On Tuesday 29 July 2008 10:20:12 you wrote:
>   > > On Tue, 2008-07-29 at 09:51 +0200, Alexander Neundorf wrote:
>   > ...
>   > > Yes, one *can* use the above features and get small features.
But
>   most
>   > > people simply can't - if only that they use some tool/lib
written in
>   C++
>   > > (and coming from the "normal" world) which simply uses them
without
>   > > thinking about space and wonder why the device won't run with
"only"
>   > > 128MB flash and run in 16MB RAM.
>   >
>   > Well, if somebody carelessly uses general purpose apps/libs in a
tiny
>   embedded
>   > project he will have problems, no matter if it's C or C++.
>   
>   Of course.
>   But it is IMHO much more easier and seductive to use the code
bloating
>   features with C++ - especially if you don't know what to do and do
not
>   realize (until it's too late).
>   
>   Evey other potential customer asks about C++ on an embedded device.
And
>   if you say "yes" they *expect* to use all that g++ allows. Period.
>   
>   Getting exceptions and restrictions to the use of C++ (including any
3rd
>   party software - known and unknown) in an offer?
>   Please be serious.
>   
>   Discussing afterwards that these templates are a very bad idea (and
need
>   to be converted to "a pure virtual class and lots of classes" to
avoid
>   code bloat and that it will cost a few man-weeks and calendar time)?
>   I can hear it already: "But you said that C++ is OK and this is
plain C
>   ++".
>   
>   > > BTW why should I use C++ if I don't use any "fancy features"?
>   >
>   > If you just skip RTTI and exceptions you have enough fancy
features
>   left :-)
>   
>   Hmm, does g++ has options to completely disabled these (and other)
>   "fancy features"? At least one could check 3rd party software more
>   easily if they actually use that.
>   
>   Multiple inheritance[0] is in my experience not really necessary (if
>   ever used).
>   I already have "Safe C" with gcc anyways (if I want and enable some
>   warnings;-).
>   OO design is a question of design and not of the implementation
>   language. I can't see much difference between
>   - declaring a class and using a method or
>   - declaring a struct and use a pointer to an instance as the first
>      parameter in several functions.
>   Leaves operator/function overloading and default values for
parameters.
>   But it adds usually libstdc++.so ....
>   
>   > Just know what you're doing if you're using templates and multiple
>   
>   ACK. But what is with the other 90%?
>   
>   > inheritance, there is no problem with them. Templates are so much
>   better than
>   > macros, and if used carefully they don't bloat the code size.
>   
>   Don't get me wrong - I'm not religiously against C++ in anyway.
>   It's just that you *really* need to know what you do and that
implies
>   IMHO for C++ that you must know how templates work/are implemented.
>   Similar for exceptions (and no, using exceptions usually doesn't
save
>   space anywhere - at least not if your calling depth is < 100). if
you
>   use them (or use a library that uses them).
>   And may need or may not need libstdc++.so - an additional piece of
code
>   using space.
>   Of course, if you have 1GB of flash and 256M RAM, who cares. But
most of
>   the devices I see are not that "fat".
>   
>   In short: It is far from easy to *not* shoot yourself in the foot
with
>   C++. At least compared to plain C.
>   
>   	Bernd
>   
>   [0]: Yes, I know what's the difference between normal and virtual
>            inheritance.
>   --
>   Firmix Software GmbH                   http://www.firmix.at/
>   mobil: +43 664 4416156                 fax: +43 1 7890849-55
>             Embedded Linux Development and Services
>   
>   
>   --
>   To unsubscribe from this list: send the line "unsubscribe linux-
>   embedded" in
>   the body of a message to majordomo@vger.kernel.org
>   More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: prevalence of C++ in embedded linux?

[Bart Van Assche]

On Tue, Jul 29, 2008 at 10:08 PM, Leisner, Martin
<Martin.Leisner@xerox.com> wrote:
> If you're embedded device has a window system, than a language like C++
> is fine...But...

C++ is suited for much more than just windowing systems. A good
example is the GOLD project, a linker for ELF files. GOLD is a rewrite
of the GNU linker (ld). See also
http://google-opensource.blogspot.com/2008/04/gold-google-releases-new-and-improved.html.

Bart.

Re: prevalence of C++ in embedded linux?

[Jamie Lokier]

Bart Van Assche wrote:
> On Tue, Jul 29, 2008 at 10:08 PM, Leisner, Martin
> <Martin.Leisner@xerox.com> wrote:
> > If you're embedded device has a window system, than a language like C++
> > is fine...But...
> 
> C++ is suited for much more than just windowing systems. A good
> example is the GOLD project, a linker for ELF files. GOLD is a rewrite
> of the GNU linker (ld). See also
> http://google-opensource.blogspot.com/2008/04/gold-google-releases-new-and-improved.html.

Is C++ intrinsic to GOLD's linking superiority over ld?  Or was it
chosen because the author fancied using it?  (I don't know).

There's been a resistance to using C++ in GNU programming tools
generally for a long time - see GCC which only recently switched to
ANSI C.  That's because they want the tools to run on lots of
platforms, and C++ templates in particular haven't been standardly
implemented until the last few years, and probably still aren't on
some platforms that they'd like to run GNU tools on.

So using C++ in GOLD was a bit of a bold decision :-)

What I can't help noticing is that GOLD, while superior for linking
straight GNU/Linux applications due to better algorithms, and
extremely knowledgable author etc. - it explicitly does not support
anything but ELF.  It doesn't support the zillions of linker
capabilities of GNU binutils ld, and the author says he doesn't intend
it to.

So it won't ever be suitable for linking some embedded targets -
you'll still need to use Binutils ld/objdump or another tool, at least
for the last step :-)

Binutils' undoing is probably the complexity in its approach to
generically supporting every kind of linkable object anywhere.  That
complexity is the reason we have the ugly 'elf2flt' instead of simply
a backend which emits uClinux executable formats.  The authors of
uClinux tools found it easier to postprocess the output than to write
another format backend.

I don't think C++ would help a lot with that complexity if you wanted
to still support lots of different formats - although another language
with versatile metaprogramming might.  (There's a lot to choose from).
I could be wrong of course.

-- Jamie

Re: prevalence of C++ in embedded linux?

[Bart Van Assche]

On Wed, Jul 30, 2008 at 12:25 PM, Jamie Lokier <jamie@shareable.org> wrote:
> Bart Van Assche wrote:
>> On Tue, Jul 29, 2008 at 10:08 PM, Leisner, Martin
>> <Martin.Leisner@xerox.com> wrote:
>> > If you're embedded device has a window system, than a language like C++
>> > is fine...But...
>>
>> C++ is suited for much more than just windowing systems. A good
>> example is the GOLD project, a linker for ELF files. GOLD is a rewrite
>> of the GNU linker (ld). See also
>> http://google-opensource.blogspot.com/2008/04/gold-google-releases-new-and-improved.html.
>
> Is C++ intrinsic to GOLD's linking superiority over ld?  Or was it
> chosen because the author fancied using it?  (I don't know).

I don't know whether C++ is intrinsic to GOLD's linking superiority.
The reason I cited the GOLD project is because of the programming
style of the GOLD source code. A quote from
http://lwn.net/Articles/274859/, about the GOLD source code:

I looked through the gold sources a bit. I wish everything in the GNU
toolchain were written this way. It is very clean code, nicely
commented, and easy to follow. It shows pretty clearly, I think, the
ways in which C++ can be better than C when it is used well.

Bart.

Re: prevalence of C++ in embedded linux?

[Haavard Skinnemoen]

"Bart Van Assche" <bart.vanassche@gmail.com> wrote:
> I looked through the gold sources a bit. I wish everything in the GNU
> toolchain were written this way. It is very clean code, nicely
> commented, and easy to follow. It shows pretty clearly, I think, the
> ways in which C++ can be better than C when it is used well.

I guess he never looked at the target interface...

>   // Relocate a section during a relocatable link.  The parameters are
>   // like relocate_section, with additional parameters for the view of
>   // the output reloc section.
>   virtual void
>   relocate_for_relocatable(const Relocate_info<size, big_endian>*,
>                            unsigned int sh_type,
>                            const unsigned char* prelocs,
>                            size_t reloc_count,
>                            Output_section* output_section,
>                            off_t offset_in_output_section,
>                            const Relocatable_relocs*,
>                            unsigned char* view,
>                            typename elfcpp::Elf_types<size>::Elf_Addr
>                              view_address,
>                            section_size_type view_size,
>                            unsigned char* reloc_view,
>                            section_size_type reloc_view_size) = 0;

I can't wait to implement avr32 support for that monster...I thoroughly
hate working on libbfd, and it looks like gold has made many of the
same stupid decisions on the interface level.

Just shows that using C++ doesn't fix a design that is broken to begin
with.

Oh, and I think "relax.cc" is missing ;-)

Haavard

Re: prevalence of C++ in embedded linux?

[Jamie Lokier]

Haavard Skinnemoen wrote:
> "Bart Van Assche" <bart.vanassche@gmail.com> wrote:
> > I looked through the gold sources a bit. I wish everything in the GNU
> > toolchain were written this way. It is very clean code, nicely
> > commented, and easy to follow. It shows pretty clearly, I think, the
> > ways in which C++ can be better than C when it is used well.
> 
> I guess he never looked at the target interface...
>
> [snip virtual method with loads of arguments which looks like binutils]
>
> I can't wait to implement avr32 support for that monster...I thoroughly
> hate working on libbfd, and it looks like gold has made many of the
> same stupid decisions on the interface level.

> Just shows that using C++ doesn't fix a design that is broken to begin
> with.

The GNU Binutils requirement was to target lots of different object
formats, and architectures, allow different ones to be interconverted
and linked together, and to run on lots of platforms.

Given those constraints, probably C was the only option at the time,
and BFD's interface, although ugly and difficult to work with, does
reflect the abstractions of different object formats and architectures
moderately well IMHO.

It's tough to make a nice design that meets those requirements.

It's unfortunate that BFD is so hard to work with that people resort
to post-processing tools and other hacks, instead of enjoying adding
new format support to it.

For all it's faults working with it, the tools themselves are very
versatile and useful compared with most equivalents.

If you have clear improvements that would simplify GOLD (without
breaking it or requirements you might not be aware of), the author may
be quite receptive to them.  He seems keen on the code being of high
quality, and he's quite experienced at working on "open" projects with
many contributors.

-- Jamie

Re: prevalence of C++ in embedded linux?

[Haavard Skinnemoen]

Jamie Lokier <jamie@shareable.org> wrote:
> The GNU Binutils requirement was to target lots of different object
> formats, and architectures, allow different ones to be interconverted
> and linked together, and to run on lots of platforms.

The Linux kernel also meets those requirements (the ones that are
relevant for a kernel that is.)

> Given those constraints, probably C was the only option at the time,
> and BFD's interface, although ugly and difficult to work with, does
> reflect the abstractions of different object formats and architectures
> moderately well IMHO.

Well, I guess it does work moderately well once you get used to it. But
there are lots of hidden dependencies all over the place. I still
haven't figured out how to un-break the debugging information after
relaxing, for example.

But what I disagree with is that these problems are somehow a symptom
of using C as the implementation language. They're a symptom of bad
design decisions IMO.

> It's tough to make a nice design that meets those requirements.

Absolutely. But does using C++ as an implementation language really
make it any easier?

> It's unfortunate that BFD is so hard to work with that people resort
> to post-processing tools and other hacks, instead of enjoying adding
> new format support to it.
> 
> For all it's faults working with it, the tools themselves are very
> versatile and useful compared with most equivalents.

Agreed. I definitely prefer using the GNU tools over the alternatives
I've seen. But that doesn't mean they can't be improved further.

> If you have clear improvements that would simplify GOLD (without
> breaking it or requirements you might not be aware of), the author may
> be quite receptive to them.  He seems keen on the code being of high
> quality, and he's quite experienced at working on "open" projects with
> many contributors.

Yeah, I suppose I should put my money where my mouth is and offer some
constructive suggestions. Right now I'm waiting for someone to get the
necessary paperwork in place so that we can work as closely with the
GNU community as we do with the Linux kernel and several other
communities.

Off the top of my head, after looking just at the target interface, I'd
really like to see
  * A few better abstractions so that the target relocation hooks
    don't need a gazillion parameters.
  * Some way to spread the target implementation across a few more
    files/classes so that we don't end up with a single
    several-thousand-lines file for each architecture. A subdir for each
    arch would be nice.

Currently, it looks like the target interface is headed down the same
road as libbfd, and that means the code will be just as unmanageable in
a few years.

I'm also curious about what things will look like once support for
complicated things like --relax and --gc-sections is added...

But I guess complaining about it here won't do much good.

Haavard

Re: prevalence of C++ in embedded linux?

[Bernd Petrovitsch]

On Wed, 2008-07-30 at 13:04 +0200, Bart Van Assche wrote:
[...]
> I don't know whether C++ is intrinsic to GOLD's linking superiority.
> The reason I cited the GOLD project is because of the programming
> style of the GOLD source code. A quote from
> http://lwn.net/Articles/274859/, about the GOLD source code:
> 
> I looked through the gold sources a bit. I wish everything in the GNU
> toolchain were written this way. It is very clean code, nicely
> commented, and easy to follow. It shows pretty clearly, I think, the
> ways in which C++ can be better than C when it is used well.

If "GOLD" is as old and flexible (and portable?) as binutils, gcc and/or
other huge software maintained to death, it is probably similar complex
and odd.
If people take a > 10 year old tool and rewrite it from scratch, I would
assume that design is better.

And I can't see any direct dependence on the used programming
language(s) if one compares running code and what is left of "design"
after years of design extensions, changes, enhancements, etc. to a new
design from scratch from the lessons learned (hopefully) from the former
one.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: prevalence of C++ in embedded linux?

[Jamie Lokier]

Bernd Petrovitsch wrote:
> If "GOLD" is as old and flexible (and portable?) as binutils,

The author says it will only work with ELF, and he does not
intend to add support for all the other things binutils does.

> gcc and/or other huge software maintained to death, it is probably
> similar complex and odd.  If people take a > 10 year old tool and
> rewrite it from scratch, I would assume that design is better.

Only true if the cruft is no longer relevant.  If the cruft is
intrinsic to the problem, e.g. supporting umpteen quirky architectures
implies umpteen quirks of cruft, then it'll be in the new design.

Btw, gcc and binutils are more like 30 years old :-)

> And I can't see any direct dependence on the used programming
> language(s) if one compares running code and what is left of "design"
> after years of design extensions, changes, enhancements, etc. to a new
> design from scratch from the lessons learned (hopefully) from the former
> one.

Some programming languages allow you to express a problem concisely
and clearly, and some don't.  That clarity then affects whether an
evolving design becomes loaded with implementation cruft or not - and
you can't always tell the difference.

Most languages are well-matched to different problem domains.

Binutils and bfd look very crufty, but I think it's hard to tell how
much of that is due to the implementation language and implementation,
or the design and requirements, and how much would exist in any
implementation on any language.

-- Jamie

Re: prevalence of C++ in embedded linux?

[Bernd Petrovitsch]

On Wed, 2008-07-30 at 14:07 +0100, Jamie Lokier wrote:
> Bernd Petrovitsch wrote:
> > If "GOLD" is as old and flexible (and portable?) as binutils,
> 
> The author says it will only work with ELF, and he does not
> intend to add support for all the other things binutils does.

Well, supporting 80% of the deployed systems requires probably only 20%
of the code;-)
But then it won't really replace binutils. And if, some quirky
hardware/systems have a problem .....

> > gcc and/or other huge software maintained to death, it is probably
> > similar complex and odd.  If people take a > 10 year old tool and
> > rewrite it from scratch, I would assume that design is better.
> 
> Only true if the cruft is no longer relevant.  If the cruft is
> intrinsic to the problem, e.g. supporting umpteen quirky architectures
> implies umpteen quirks of cruft, then it'll be in the new design.

Yes, but one can make a better design in always knowing/planning to have
hooks here and there and everywhere.

> Btw, gcc and binutils are more like 30 years old :-)

That doesn't make it better;-)
I was too lazy to search for more exact numbers.

> > And I can't see any direct dependence on the used programming
> > language(s) if one compares running code and what is left of "design"
> > after years of design extensions, changes, enhancements, etc. to a new
> > design from scratch from the lessons learned (hopefully) from the former
> > one.
> 
> Some programming languages allow you to express a problem concisely
> and clearly, and some don't.  That clarity then affects whether an

And if C is too low-level, one abstracts with functions etc. I call that
"design" - independent if the design existed before the source or if the
design evolved over years with the software
And yes, at first it is enough to add a parameter and/or function here
and there without breaking implicit or explicit assumptions.
But at one point from a larger view, the "design problems" will be
obvious and one can either solve them (investing time/money for
effectively no real gain in features and/or functionality, just only
cleanups or refactoring of parts or whatever one wants to call it) or
lives on with patching/maintaining the software to death.

> evolving design becomes loaded with implementation cruft or not - and
> you can't always tell the difference.

Yes.
And over the years and decades, the implementation evolves with the
problems - new and existing ones. If the design doesn't involve - which
IMHO implies refactoring of existing, tested and working code(!)
possible breaking it - you have at some point such a mess that each
"trivial" enhancement takes age (and breaks again somewhere else
something).

> Most languages are well-matched to different problem domains.

Maybe. IMHO these differences are almost nothing compared to the below
point:

> Binutils and bfd look very crufty, but I think it's hard to tell how
> much of that is due to the implementation language and implementation,
> or the design and requirements, and how much would exist in any
> implementation on any language.

IMHO it's (mostly) independent of the implementation language:

If changes in design are not completed (including removal of old
deprecated stuff or at least push it in peripheral places where nobody
cares;-) in the implementation (for whatever reason - no one does it, no
one wants to pay it, one wants to support every API indefinitely, ....),
it will lead more sooner than later to unmaintanable crufty software.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: prevalence of C++ in embedded linux?

[Jamie Lokier]

Leisner, Martin wrote:
> I've found you can understand spaghetti C code with some effort -- its
> nearly impossible to understand spaghetti C++ code.  Much professional
> programming is "kitchen sink mentality" -- if there's a feature, use it.
> 
> I find it interesting K&R is about 200 pages, Stroustrup is 1000+ pages.
> What percentage of the 200 pages is understood by the average C
> programmer versus the 1000+ pages by the average C++ programmers?
> 
> I program by the quote by Einstein "Things should be as simple as
> possible, no simpler".
> 
> Much of the C++ code I've seen has more complicated implementation
> details than the problem being solved (I'm a believer in Halstead
> metrics, a lot of solutions I've seen in C++ would be much smaller in
> C).  Of course, that's the solutions in C++ I've seen...not all of
> them....

Ok, but most of what you say applies the same to "generic" programming
and not particularly to embedded.  I.e. if you agree with your points,
you won't use C++ much in general, and if you disagree and like C++ in
general, then why not use it for embedded as well.

> I think C++ lends itself to coming up with complicated solutions to
> simple problems...(of course really good C++ is simple and
> clever...but much C++ I see is poorly designed raw overcooked
> spaghetti).

If you think C lends itself to simple solutions, go read a Linux
kernel sometime :-)

> Also its very useful to have an understanding how the hardware works in
> systems where memory/time is an issue (and it almost always should be an
> issue).  I have a good understanding of what will happen in my C
> compiler 
> (a good algorithm in C runs rings around bad algorithms in assembler).
> [nowadays, instead of processor performance, you think about cache
> performance].  I doubt there's generally a good understand of time/space
> of C++ features in the compiler and standard library...]

Actually, the C++ standard library specification _defines_ time
requirements for many of its algorithms.  That's better than C - in
theory.  (Whether implementations follow the spec that far in practice
is a different question.

I can honestly say I've both read and written simple to understand,
and lousy and complex C code.  And the same with C++.

For some problems, C++ has expressed the solution far more clearly
than the equivalent C.  Most notably in a video game with lots of
characters and representations of physical objects, and in a GUI -
very object oriented systems by nature - fit a C++ expression very
well.

You can imagine in a video game, time/space performance is critical.
Some understanding of what goes on behind the scenes in C++ is very
helpful to manage performance.  I guess knowing C and machine code
helps one's understanding of what a C++ compiler produces :-)

Aside from time/space performance, another factor in many types of
embedded programming is time to deliver the product - or how good can
you make it in the fixed time available.  If C helps, go for it; if
C++ is familiar to you and gets you a better looking product in the
same time, though, it might be prefereable for some parts.  (Same for
choice of libraries, tools, etc.).  That really depends what kind of
device you're making.

-- Jamie

Re: prevalence of C++ in embedded linux?

[Bart Van Assche]

On Tue, Jul 29, 2008 at 9:40 AM, Marco Stornelli
<marco.stornelli@coritel.it> wrote:
> Like Linus Torvals said "...C++ is an horrible language" :)

Some C++ language features are indeed not very elegant from a
language-theoretic standpoint. But that doesn't matter when writing
embedded software -- what matters is that C++ allows to make source
code a lot more readable than the C programming language. And if you
don't like the overhead introduced by features like exceptions or
RTTI, you can still pass -fno-exceptions -fno-rtti to gcc.

Bart.

Re: prevalence of C++ in embedded linux?

[Richard Danter]

2008/7/29 Bart Van Assche <bart.vanassche@gmail.com>:
> On Tue, Jul 29, 2008 at 9:40 AM, Marco Stornelli
> <marco.stornelli@coritel.it> wrote:
>> Like Linus Torvals said "...C++ is an horrible language" :)
>
> Some C++ language features are indeed not very elegant from a
> language-theoretic standpoint. But that doesn't matter when writing
> embedded software -- what matters is that C++ allows to make source
> code a lot more readable than the C programming language. And if you
> don't like the overhead introduced by features like exceptions or
> RTTI, you can still pass -fno-exceptions -fno-rtti to gcc.

IMHO choosing a language is like choosing any other tool to get a job
done. I wouldn't use a screwdriver to bang in a nail (um, actually, I
have and it ruined my screwdriver so I won't do it again) and same
goes for programming languages.

For low-level programming, such as kernels and device drivers, C and
some assembly is probably the right choice in most cases. That is not
to say that C++ or any other language could not be used. I know of at
least one OS written almost entirely in C++ (drivers were objects that
could be passed between devices to help them communicate with each
other, very neat).

Looking at something like graphics programming C++ makes a lot more
sense. It is natural to think of a window inheriting properties from
the widgets that implement it's functionality. Qt and wxWidgets are
good examples, or Swing for Java. But of course Motif and GTK are
written in C and work perfectly well too. I'm not sure how easy it is
to "inherit" in GTK but vaguely remember it was not exactly trivial in
Motif. To me at least C++ makes more sense here.

Scripts also have a very important role. I am probably in the minority
when I say that I like Tcl, but used for it's original purpose it is a
very useful language. There are many cases where I would chose to use
Tcl or Perl or sh scripts rather than C, C++ or Java.

The resources of the target system are also important. Many "embedded"
systems these days are as powerful, if not more so, than my laptop.
For these systems you have a lot of freedom. For others there may be
limited RAM, disk space or other resources. I am often asked about
removing Perl from the systems my customers use because of the large
disk footprint.

So let's not be too hasty to label any language as bad. Each was
developed to address a need. Trying to use the wrong language for a
particular purpose is the bad thing.

Rich