2008-02-28 07:20 AM
C++?
2011-05-17 03:24 AM
As mentioned by someone else you can do and i do use object oriented design in C (without a heap) (and use c++ for windows apps where there a mmu).
However if you download the anglia toolchain they have a c++ example hello world type program, havent tried it myself but theres a linker script and sourcecode :) http://www.st-angliamicro.com/software.asp (\Program Files\Anglia\IDEaliST\examples\stm32\hellocpp). *curious* Can i ask why you want c++ (and so dynamic memory) for embedded as preference?2011-05-17 03:24 AM
I
at last! I tried Anglia but had some problems, maybe something broke when more runtime was needed, or maybe it was me, I really couldn't tell you now. I need c++ cause I almost vomit when I have to program in c. it's an horrendous experience for me, I suffer, really. c is a portable assembler that doesn't support abstraction. it's true, you can apply OO principles to any language, including real assembler, but the end result is that you're doing the work of a compiler. and I want less work, not more. c won't understand your OO work and its type system won't help you or check on you. and the mapping (compilation) process you have to do is tedious and error prone. plus there's much more to c++ than objects, like generic programming and exceptions. I believe there's not a single reason to prefer c over c++. c++ doesn't have to be one bit slower or less space efficient than c, and in the real world programs can be made more efficient in c++. (in the extreme of complexity, you can say that programs can at lest be *made* in c++, in contrast with assembler or c.) I chose the microcontroller with the absolute requirement of c++ support. I need it cause I'm involved in a sort of complex project. > why you want c++ (and so dynamic memory) [...]? the use of c++ does not imply dynamic memory in any way. but in my project I need it. I'll have realtime periodic code using fully static memory and the user interface (complex) running on the background. the UI uses all the not very deterministic services like heap and exceptions, while the realtime part doesn't. (btw, if you try c++ on the STM32 and find that the binaries are too big, you could disable exceptions in the makefile so that the stack unwinding code is not linked.)2011-05-17 03:24 AM
Quote:
I believe there's not a single reason to prefer c over c++. Well C is much simpler and easier to learn for non software experts like me. But you are probably well versed in C++ so it doesn't matter to you. As an electrical engineer and not a software developer, C is much more practical for me. I tried C++, but getting it to create efficient small programs was like... well like you programming in assembler and C, a horrible experience. I constantly had to jump through hoops and monitor the generated code to keep it under control. C++ was great on a PC with gigs of memory and no hard time contraints, but for me on an embedded project it was like using a 10 horse power table saw to cut balsa wood for a model airplane kit, way too much tool for the need :)2011-05-17 03:24 AM
I'm an electronics engineer too, I totally get where you're coming from. I've got this friend (also an EE) that makes access control products. He works entirely on 8051 assembler, and he does pretty complex things, considering. I don't know how he does it, but he does. There's really no getting through to him. He says learning C involves time he doesn't got. He says he doesn't really need the complexity of C, and that's evidenced by his making of adequate products without it. He says assembler is just simpler, but you and I know it's not.
Think of the cost: the ugliness of the job, the unnecessary hours, the difficulty in adding a feature later, the overall inferior quality of the result, etc. He incurs all these costs because he thinks assembler is simpler than C. In the same sense that that's not true, your statement:Quote:
C is much simpler and easier to learn for non software experts like me. is also false, IMHO. In the words of Bjarne Stroustrup, C++ creator, C++ is first and foremost ''a better C''. As many rough corners of C as possible were smoothed out without breaking compatibility, and many new features were introduced. You don't have to know them all, you can learn as you go, as C++ was designed with this principle: what you don't know won't hurt you. Think of how these features can improve your C programming in a flash, without you having to know anything about OO: -const modifier (retrofitted into C): cleaner, safer and faster code -inline functions (retrofitted into C): cleaner, safer and faster code -definition of locals anywhere in code (retrofitted into C): a little bit of sanity added to C! helps the optimizer (I believe typedef also comes from C++) -references: automatic pointers without the cumbersome * and -> operators -exceptions: handling of errors at the right abstraction level (no more checking errors after every call), higher non-error performance -templates: turns those ugly macros into safe and efficient code -template libs: safe high performance containers without casts -operator new/delete: safer malloc without casts -operator overloading: safer smaller and faster printf and scanf, syntatic sugar everywhere on libraries -class libs: a language with more types, such as efficient complex numbers, that you can use like they were built-ins (no need to know anything about OO), easier/auto resource management via constructors and destructors forced initialization (under some circumstances): safer code These come out of the top of my head now, I'm sure there are many others. The best advice that I can give you is to read The C++ Programming Language by Stroustrup ASAP. The book, from a literary standpoint, is the best written technical book I had the pleasure of reading. So clear and sharp, it sure is a reflection of the author's mind. Also, C++ itself is beautiful and I'm sure you'll get hooked. I read this book at the beach in the early 90's. I didn't know C at the time (it's not necessary), and this was many months before I had my first compiler. I couldn't put it down.2011-05-17 03:24 AM
the book I frequently use is Object-Oriented Software Construction by Meyer, it's more a generic book on OOD, which I like
anyway, I believe assembly, C and C++ (and more advanced graphical programming tools Simulink for that matter) all have their uses, like a carpenter uses a hand saw, power saw and table saw on the same project, you have to pick the right tool for the job, and maybe some jobs a combination of all three for a small micro like the STM32, I prefer assembler and C, I simply don't want the level of abstraction C++ allows you, hiding details in an embedded environment can be a total disaster, I want them in my face all the time reminding me of the consequences of doing this or that. In addition, for micros I've seldom been able to blindly use someone elses objects (including ones that I have written a long time ago!), classes also fell apart when I try to extend them to new and different processors, I couldn't correctly predict the future when I created them, so they lack in some feature and have to be rewritten (or if I use inheritance they become too cumbersome and too complex that they become simply untestable or very time consuming to test). I agree it will work for REALLY basic things like complex numbers as you indicated. The construction of the software is far more important to me then the language used so I really don't dwell on it too much. :p2011-05-17 03:24 AM
I'm in agreement, with ''they all have their uses''. c++ is easier to write oo code in to start off with, but i don't find its really any more complex in c when you get used to it - its just not as intuitive to start off with.
I've recently finished a really tight (with regards processor time) project on an str710 which i don't think c++ would have compiled to fast enough for. In theory you don't need dynamic memory in c++ but as soon as you start using classes its very _difficult not to and almost defeats the point and beauty of c++, likewise yes in theory they should compile to the same code though i don't find they do always (sometimes yes but not always:( ). Thanks for the disabling exeptions tip i'll bear that one in mind:)2011-05-17 03:24 AM
I spent a week or so trying C++ just to get:
1) overloadable functions (e.g. buffer.append(char c), buffer.append(short s)) 2) more rigorous type checking for enum's 3) ''namespaces via classes'' to make my code more readable. I got efficient compiled code, and it worked!, using Rowley crossworks and Ride7, but neither would reliably show me data during debug sessions. Rowley's startup clearly runs constructors for static data, however all mine ended up being inlined so I didn't actually watch any execute during startup. I didn't see any evidence that ride7 supported static construction. I ended up with C as I spend more time debugging than crafting code. I still use eclipse when I am creating large amounts of new code, however I could never get eclipse+yagarto to compile more than once without doing a 'make clean', and I could never get it to run the debugger. I ended up buying Rowley as Ride7 very frequently crashed during debug, and also crashed at the end of compilation, when there are significant syntax errors.