I've used ChibiOS before and like it a lot. No affiliation...
But beyond just ensuring task delegation at runtime it has to do with how the source itself is organized for one's own sanity (and ideally the sanity of anyone who has to work on it after you.)
In particular I see Arduino/AVR code which, even though the compiler the IDE is using is a pretty full featured modern C++ compiler, is pretty much written like C with headers that have dozens or hundreds of #defines and preprocessor macros and...it's a headache that's not understandable or modifiable by anyone but the author.
It's frustrating because it doesn't have to be that way, it's 2017, compilers are very smart and the "conventional wisdom" that metaprogramming and real OOP techniques (not just sticking plain C code in a class) leads to slow or bloated code simply isn't true anymore, even on some 8 bit archs.
I guess the best I can offer you is that yeah, it does retain a lot of messy stuff for reasons of backwards compatibility. Much of which you don't ever have to use on new projects. So you set guidelines for yourself and/or your employees (or read a book on what the best standards and practices are for development in the language as of 2k17) and then you adhere to them. There's lots of stuff that's deprecated and it's not difficult to find out what it is.
As an example related to my original post on the desktop at least smart pointers became part of the core standard library as of C++11. Historically one of the big complaints against C++ (on desktop archs at least where dynamic allocation is done regularly) was the ease in which one could leak memory by not remembering that it's not a garbage-collected language; every use of "new" to acquire a resource _must_ be accompanied by a corresponding delete/free or you _will_ leak.
By using smart pointers and enforcing a standard where you never actually call "new" without wrapping that call in a structure that manages the resource's lifetime automatically (except in the rare circumstance you actually have to write an allocator for the resource...) you will never leak, by design. The only thing "raw" pointers are good for in the new order is for observation, not modification. Passing a raw pointer to a function in a fashion like:
void my_func(Foo* my_ptr) {....
without it being const-qualified is simply _wrong_ in nearly every case.
And the objection then might be, "yeah, great, but now you've got these objects managing the lifetime of other objects and it's going to bloat the code and slow execution even more." But in practice it almost never does in any significant way vs. what you'd have to do to get the same functionality by hand. e.g. if you create some smart pointer structure that's functionally equivalent to calling "new" in one function and then calling "delete" on the resource in another that's precisely what you get when you look at the asm.
The compiled code has no knowledge of structures, or objects, or OOP, or polymorphism, or inheritance, or anything of the kind, and there's no reason it has to.
On a sunny day (Sun, 01 Oct 2017 13:08:59 -0700) it happened John Larkin wrote in :
Nice, I have longer logs on disc than 24 hours, could use 'gnuplot' to display it.
Yes, this thing has a webserver too, with all commands remotely available. But ultimately I can ssh to the Raspberry and just change things and recompile from anywhere in the world if it has net connection But it is basically designed to be used standalone on a boat, with local WiFi for ..pads and other computers. Have some incredible long uptime tests...
Every now and then I think of something and add that. There is a little PCB in the Raspy mounted on the headers, with compass, acceleration sensor, and air pressure sensor. All other sensors and control are now via ethernet connected to it, the GPS module hangs directly on the raspberry serial port pins via a cable so you can place it in a place with good reception.
formatting link
The Raspberry drives 2 i2c busses, each driven by different threads. Website REALLY needs updating...
On a sunny day (Sun, 01 Oct 2017 14:37:34 -0700) it happened John Larkin wrote in :
My domain was renewed (at godaddy) just a week ago. I have some server space there and an ssh connection. Who needs dropbox? The backup server is here at home, never needed so far. It is just a few dollars a year and saves a whole lot of tinkering. If something does not work it is my own fault...
On a sunny day (Sun, 1 Oct 2017 18:01:27 -0400) it happened bitrex wrote in :
10 thousand lines is normal for my C programs. And a whole lot of source files. And a whole lot of threads running.
What 'ORGANISE', something so simple????? You have been assimilated.
The usual bull. Most 'higher level' languages are not maintainable at all. Plenty of examples in the real world where multi-million dollar projects totally failed. Here the tax office for example, there also was a luggage handling system in the UK, the millions for police database reorganization here, etc etc etc. No end to it.
Top down ONLY work if you know the basics bottom up. A painter is no architect, no matter how nice paintings he makes of buildings, and those go up in flames too. Time will eat it all.
And then archaeologists will wonder how could they have build so much crap and for what.
On a sunny day (Sun, 1 Oct 2017 19:00:45 -0400) it happened bitrex wrote in :
Na, it is released to encourage people to use their brain. I get plenty questions: 'Do you sell that', I am willing to pay for it' sort of thing, but I leave it to China to implement it in the next firmware (they did I think). It seems (from correspondence) that people in Europe have few problems and where even helpful pointing out things.. The 'do you sell it' request coming from the US. Code is very readable and has plenty of comments. No, it is not for a beginner, but what is a beginner [1]? I used to read a lot of open source code, mostly C though, it is like reading other languages, and writing other languages. No problem. But you seem to be waiting for Esperanto ...
Maybe yours. You are dreaming.
[1] long time ago I wrote a CP/M replacement in Z80 asm on a ZX81 using tape drive, load times per error 10 minutes or so, and designed and added the needed hardware, and soon enough it ran the C80 C compiler. For the fun of it. It had a ramdisk and was faster than the first IBM PCs. Code is on my site, as well as the circuit diagrams. All you guys do, except JL and PH, is talk, never show your code... And that talk makes NO SENSE from a real programmer POV. Take it. As a social thing, yes, long time ago in sci.physics when I attacked Sam Wormly about his GlowBallWorming jive he explained to me that that group was not about physics but some sort of social club. Sammy is gone, he took his human made warming crap and left when Trump came I think. The level in that group is indeed now below that at the local bar as far as physics is concerned. It is the same old people spouting the same old nonsense, sci.astro the same.
So lets see what you have code related. Else listen.
Looks by the way if you got that remark from my site:
formatting link
quote myself: ' If you make it to that point my hat off to you, I would have aborted long ago ;-) (and write my own version I think).
But maybe all the code will lead to more dancing creations. ' Violation of copyright, I was first!
I do mostly simulation and instrument code, both of which are a natural match for C-with-classes-and-a-few-templates C++ because they deal with actual objects.
Cheers
Phil Hobbs
--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics
160 North State Road #203
Briarcliff Manor NY 10510
hobbs at electrooptical dot net
http://electrooptical.net
That's one of the main warts with C++: combining class libraries . If they're doing completely different things, you might be okay, but if they overlap at all you're probably screwed. It has got gradually better over the years as the standard library has ballooned, but that's replacement rather than reuse. In C++98 it was a complete disaster.
Cheers
Phil Hobbs
--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics
160 North State Road #203
Briarcliff Manor NY 10510
hobbs at electrooptical dot net
http://electrooptical.net
Speak for yourself. Many people seem to manage to understand a good deal of C++. It does have its "advanced" parts, however, that are best left to a small number of experts. Not many C++ developers really understand how something like unique_ptr actually /works/ - but that's okay, they don't have to understand how it works in order to use it.
C++ is a big language. That does not make it bloated - features are added when they are useful. Unlike, say, Python, C++ puts a lot of emphasis on backwards compatibility - this has the unfortunate side effect that features get left in even after they have been replaced by something better.
Yes, some C++ language designers were a little surprised when they realised how much could be done with with template metaprogramming. I doubt if the designers of C had imagined that there would be an IOCCC competition when they developed that language. The C++ folks were not the first people to make a tool and then later find it can be used in surprising ways.
The FQA is /not/ necessary. It is mostly crap. And many of the good points that can be found with enough digging, have been addressed in later C++ standards.
The idea now with the standard template library is that if you have some container that say supports the Iterable "concept", and supports the "Allocator" concept, and you have some algorithm that conforms to the "Algorithm" template that you want applied to an iterable in a container that's allocated using a custom memory allocator, it just works. Doesn't matter whether the container you choose is a vector, map, list, tree, queue, string, whatever.
I guess the best I can say is "works for me" and I've never encountered any obscure problems or showstopper bugs in practice. Of course how you design your "plug ins" and what data structures and algorithms you choose for a particular task can have a big impact on code size and performancem but that's a design decision and it will always be that way.
You are stuck in a grove. Templates can be recursive - that is an intentional and useful part of the language. It is something that people wanted in C macros (it gives about 9 million hits on google) but could not get - C++'s templates give them that. Once you have recursion, you either have artificial limits or you can continue indefinitely. In theory, it was a useful feature for doing compile-time calculation and generation of tables, but it was cumbersome and user-unfriendly - constexpr functions in C++11 and C++14 are much more convenient.
If you want to discuss specific points in the FQA, then give them. Most of that document is worthless or at least outdated.
Examples?
I am not denying that you can get subtle bugs with C++ - far from it. It is a complex language, and people use it to write complex code, so bugs certainly do occur. I just want to know exactly what you are thinking of.
I have always fixed compiler version (and library version, and compiler flags) for my projects. That applies equally to C, and to assembly. I don't see such subtle bugs as being a big risk in my coding (whatever language), but any risk is a risk. There may also be bugs in the compiler, bugs in the library, etc. When I have taken a project, compiled it, and had it fully tested and accepted by the customer, then it is fixed. If I pull it out the archives 5 years later (or 21 years later, which is my record), then the first thing I do is a complete rebuild and check that the binary files are /identical/. Then I know I am in exactly the same position now as I was before. You only get that by locking down development tool versions.
To me, this is /flexible/ - not brittle. I lock versions so that I can do the checkout and rebuild on a variety of computers - usually I check on a Linux machine and a Windows machine at work, and a Linux machine at home.
Seems at some point some folks thought OOP was "about" inheritance and polymorphism and huge class hierarchies and..it's not about that. It's about modularity, genericism, and re-use. I barely use traditional vtable-based C++ virtual methods and classes at all.
In large applications, a particular pain point has been memory management across multiple libraries. Yes, you can avoid/delay the problem to some extent by religiously copying data as it "enters/leaves" each domain. But that can be expensive and cache-busting - which rather negates the claimed efficiency advantages of C/C++.
Everything I've built seems to have been built both top-down and bottom-up simultaneously. And yes, they have met in the middle :)
It has always horrified me that many of the "design processes" slavishly and dogmatically mandate either one or the other, but not both.
I suppose that can work /iff/ your current project is merely a small delta from your last project - but I've never had the "luxury" of repeating myself in that way.
Backward compatibility is one of those tails that /needs/ to wag the dog. But I don't see the relevance to the templates example: the designers were starting from scratch and didn't comprehend what they were creating.
One alternative is, of course, to start over with a new language that avoids the cancerous mess. For many purposes Java did just that, and back in 1997 I was gobsmacked at how many
*mutually compatible* high quality libraries were available in less than a year - far more than C++ had failed to produce in 10 years.
It will be interesting to see how Go and Rust perform in that respect; they seem to be gathering momentum, but time will tell.
That /might/ be OK /iff/ *all* the libraries you are using follow the same patterns. If not, you are up the creek and/or crossing your fingers.
You can "cast away constness" I believe, so in large systems the utility of cost is somewhat dubious.
There are significant benefits to strongly typed languages and runtimes like Smalltalk, Java and others. In particular, you can examine the entrails of /other people's/ data structures secure in the knowledge that you are looking at a horse and not a camel, and that some unknown bugger hasn't accidentally treated the data structure as a speedboat.
Small systems where a single developer can be expected to understand everything are fun, but rare and limiting.
Between occasional annoyances, it's actually very nice. I can drag/drop a file or folder into my Dropbox folder, from any PC, and it appears on (actually IS on) all my PCs. It does a lot of intelligent compression, so it synchronizes fast. It keeps some level of old versions of files. It right-click generates web links that I can give to other people. If it goes down, ot a PC loses connection, all the files are there on all the PCs anyhow.
Gropboc is free for some number of gbytes; I pay something like $9 a month for 100G and can link any number of PCs.
--
John Larkin Highland Technology, Inc
lunatic fringe electronics
On a sunny day (Mon, 2 Oct 2017 08:45:47 -0400) it happened Phil Hobbs wrote in :
This is dynamic, and in plain gcc:
formatting link
same:
formatting link
same, objects and those move, position prediction:
formatting link
So it is what do they call it? Well, not a prerequisite to use some 'object oriented' language, on the contrary. Did you know that libforms has a GUI generator (fdesign)? You just plonk the buttons, menus, browsers, and graphs and other funny 'objects' on one or more forms, it will write the C code for you (callbacks) and all you have to do is fill in your code. libforms is also written in C, that library is extremely small: 1844127 Jul 13 2012 /usr/lib/libforms.so.1.0* timeless, compare that 1.8 MB to all that other crap like Qt was, or that other thing 'gnome', what not. libforms was actually a university project. If I use (and I have for projects) 'fdesign' I can put together a GUI however complicated in less than an hour. In C. I always do it by hand though, layout is fun.
That's not just a C++ problem. On Windows I used to have to use static linking because one library wanted to allocate memory in a DLL and free it in the main program. Oops.
Cheers
Phil Hobbs
--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics
160 North State Road #203
Briarcliff Manor NY 10510
hobbs at electrooptical dot net
http://electrooptical.net
C++ works very nicely with the both-ends-against-the-middle approach, because at each step you can design the interface without having to code the underlying functions yet (top down) and you can write basic functions that eventually get pulled in as private members of whatever class you need them in.
Cheers
Phil Hobbs
--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics
160 North State Road #203
Briarcliff Manor NY 10510
hobbs at electrooptical dot net
http://electrooptical.net
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.