Date: Wed, 09 Jan 2002 14:58:19 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: "Gary W. Swearingen" <swear@blarg.net> Cc: freebsd-chat@freebsd.org Subject: Re: Use of C++ with kernel and in embedded software. Message-ID: <3C3CCB0B.76178BF1@mindspring.com> References: <g3bsg31a6s.sg3@localhost.localdomain>
next in thread | previous in thread | raw e-mail | index | archive | help
"Gary W. Swearingen" wrote: > What are disadvantages of writing kernel modules or device drivers > in C++? (I'm not sure it's practical or even possible without patching > the kernel.) Are there such modules? (My quick search didn't find any.) The primary disadvantage is that it's the crt0.o code that calls the .init and .fini section entry points to do things like pre construct template derived class instances, pure virtual base classes, and the like, and that the kernel itself is not linked with any code that does that, so you are really limited in what C++ constructs you are permitted to use. A secondary problem is that the object file format was not set up correctly with attribution when C++ was released, and this was never corrected, because compiler writers are lazy, and it would have taken a modified linker to deal with the object files after that (very much the same reason we use prototypes for argument checking in ANSI C, instead of having the linker complain about mismatches, which it could easily do.. or even emit glue code to do the argument conversion automatically). The upshot of this is that C++ compilers engage in "decoration" of symbols, using the symbol itself, rather than a seperate field in an expanded symbol table, to do argument and return value attribution. The upshot of this is that the linker does not expect to link C and C++ code together, so you have to compile everything with C++ symbol decoration, or make specific glue modules for the symbols to resolve correctly. > In embedded software development, what fraction of current development > (not legacy code) is done with each of C and C++. I fear it's something > like 85%/10%, but I really have nothing to base my guess on. Maybe you > don't either, but I suppose that several hunches are better than one. It depends on what you mean by "embedded". For the strictest possible definition, almost zero code is written in Java or C++ or languages other than assembly, Forth, and C. For less strict definitions, you could use FreeBSD or Linux as an embedded OS, and then the amount of code depends on what the project is (with Perl probably beating C++ out by a wide margin). FWIW: I go by a moderately looser definition, and I've used C++ in embedded systems implementations before, as well as C, Perl, assembly, and Java. Java is not typically a good embedded language, because you can't deterministically control the amount of RAM your JVM uses because of garbage collection; one of the reasons I ended up using C++ in the particular project in question is that up front allocation with explicit deallocation was pretty much required to reasonably fit in the required memory footprint. > (I need to retrain myself in C or C++, for eventual use in embedded > software development outside the M$ world. I hate to resort to crude C > after my long experience with equally-crude FORTRAN and with elegant Ada > and so would prefer to concentrate on the compromise of hacked-up C++, > but I'm wondering if there's too little C++ work in embedded software > development. Is almost all C++ work in high-level stuff, "designed for > Windows(TM)", etc?) Most C++ programmers are actually writing C code, anyay. So are most Java programmers, if you come down to it (one of the most in-love-with-Java people I ever met wrote code that was effectively C code, and took no real advantage of Java at all, and even intentionally defeated some object oriented protection mechanisms by permitting the instancing of uninitialized -- read "unconstructed" -- objects, that had to have an explicit, seperate initialization done on them using a member function). The problem with C++ -- and Java -- is the same as the problem with C: it permits you to get around some of the protection mechanisms which are supposedly your reason for choosing the language in the first place. Learning C++, you will effectively learn C, as well, so you might as well know both. As far as the job market goes, though, the majority still require C, rather than C++ or Java, though you can sometimes get paid a premium for Java, if someone from the corporate office has fallen in love with the idea, and so there is money to pay the premium required to get people to code in the language. It's pretty easy to avoid situations like this (if you aren't just a mercenary who doesn't care, except to get the largest possible paycheck, then you will do whatever pays most anyway), since they ask for stupid things like "10 years Java experience", not realizing how long the language has been around, or that to even have 6/7 years, you have to be one of the people who worked on it back when it was "Oak". 8^). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C3CCB0B.76178BF1>