Re: prevalence of C++ in embedded linux?
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 -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: prevalence of C++ in embedded linux?
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 -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: prevalence of C++ in embedded linux?
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 [EMAIL PROTECTED] 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 -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: prevalence of C++ in embedded linux?
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 [EMAIL PROTECTED] +39 06 72582838 -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: prevalence of C++ in embedded linux?
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 KR 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: [EMAIL PROTECTED] [mailto:linux-embedded- [EMAIL PROTECTED] 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
Re: prevalence of C++ in embedded linux?
On Tue, Jul 29, 2008 at 10:08 PM, Leisner, Martin [EMAIL PROTECTED] 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. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
