On Friday, April 26, 2002, at 09:29 PM, Curtis L. Olson wrote:
> Arnt Karlsen writes: >> ..can C code be generated from C++ or Java source without undue >> difficulty using some tool? How about C++ from Java source? > > Originally, back in the old days, C++ was implimented via a translater > that produced "C" code for final compilation. So, yes C code can be > generated, however I have no idea if these old tools are still > available. I'm sure they were commercial/proprietary (not open > source) at the time they were being used before native C++ compilers > existed. > > So by definition, anything you can do in C++, you can do in C. > >> ..or is C++ source as "easy" to read as C source for the FAA guys? > > I personally believe that code readability in most cases is more > dependent on the author of the code, and less dependent on the > language it was written in. But, true, some languages can help or > hinder readability ... Intercal is [intentionally] one of the most > difficult languages to read. I always thought that Modula-2 was one > of the more readable languages out there. Some people say Python is > like writing pseudo-code. Personally I still don't grok python very > well, which means readability is also dependent on the reader's > experiences. > When you state your concerns about the FAA, I assume that you are talking about avionics software, probably DO-178B level C or higher. The vast majority of modern (1987+) avionics software that I have seen is in Ada, largely due to the structure that is built into the language. With Ada's strong typing and package structure, you really need to work to do something bad. The little bit of C software that we let wind up in our final software is *very* process driven. This includes design reviews, code reviews, test plans at design time, and test procedures that are traceable back to top-level requirements. While our Ada software goes through these same steps, extra care is taken with C (we restrict what can be used), largely due to the lack of safeguards built into the language. The biggest problem I see with C++ and the FAA is that it is VERY hard to guarantee that C++ will not do any dynamic memory allocation. If you step through the STL code with a debugger you will be amazed at how much is going on there (strings are nasty). Since avionics are embedded systems, the freeing of dynamic memory is a Very Bad Thing. If you are developing software that will be used to test avionics software, then the rules change. The same is true for level D or lower software. With test applications, you need to go through a verification process, which my team will be doing very shortly. While the process demands are not as strict as it is for the flight software, I tend to require the same level of process as our flight code. We tend to share people across programs, and you never quite know where your software will be used next. >> ..agreed, agreed, and ugly code is not airworthy. Needs to be clean >> and pretty and easy to read and understand. Linus and the kernel guys >> enforce a coding style, how far off it are we? > > There's no practical way to ensure a coding style without automating > the [re]formatting in some onobtrusive way. So far I haven't found a > C++ beautifier that produces what I consider acceptable results (or > rather which doesn't produce unacceptable results.) > > These questions can really lead into a religious debate so please > everyone be nice if you weigh in. :-) > From the little bit of investigation I have done, it looks that coding styles within an area are pretty consistent but can change drastically from function to function. I know that MY coding style would probably freak some people out ;) Probably the best way to guarantee a consistent coding style is to have a published coding standard. This could increase the load on the maintainers as they will need to verify that everything meets the standard before committing changes. >> ..can the whole issue be as simple as enforcing coding style for >> easy readibility??? > > The question is though, from a practical standpoint, how do you > enforce a code style. Do you want to do it manually yourself? Do you > expect someone else to do it? Who has the time? If not manually, we > need to find an acceptable automated approach. I'm open to > suggestions, maybe there's a new tool on the scene or something I > haven't seen yet? > >> ..my "airworthy" questions comes from seeing the potential in >> airworthy code in avionics etc, built from a subset of FG and >> linux some day. Until someone comes up with a better idea. ;-) > > Another approach would be to build the 'airworthy' code on top of the > lower level flightgear/simgear/plib code that is tried and trued and > stressed tested over and over again. > I think I can safely say that FlightGear will never be airworthy (unless it is level E, which, in this case, means it will not be used for flight). There are no documented requirements, design, evidence of peer reviews, interface documentation, test procedures (especially ones mapped to the requirements), etc. While you could, in theory, spend enough money to certify almost any code, it is best if you think about airworthiness from the onset. The structural coverage alone would be prohibitive (i.e., prove that every branch of every line of code maps to some requirement and that you have a test that exercises them). >> ..hummm. Why is the Linux kernel not written in C++? ;-) >> Hurd? Free|OpenBSD? Anyone? Any OS written in C++? >> That _is_ possible? > > History? Momentum? Biases of the leading kernel authors? Bugs in > g++? There was a time when the linux kernel could be built with g++, > but there were issues and the result wasn't as stable as when compiled > with C. From that perspective you make a fair point, however, this > was a few years ago, g++ get's better and better, and coding a project > from the bottom up in C++ is a *lot* different than taking one that is > developed in C and trying to compile it with a C++ compiler. > I seem to remember seeing something on slashdot a while back concerning object oriented OSes, but I don't know if any were written in C++. Remember that C++ does have some additional baggage that you may not want. Dynamic memory allocation, exception propagation (how do you pass an exception from kernel to user space?), changes in how inheritance works (there is this new way to do it that I can't use because of how the OS defines it). And you still get stuck with supporting older languages (FORTRAN, C, Pascal, etc.). My US$0.02, Jonathan Polley > Regards, > > Curt. > -- > Curtis Olson IVLab / HumanFIRST Program FlightGear Project > Twin Cities [EMAIL PROTECTED] [EMAIL PROTECTED] > Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org > > _______________________________________________ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
