[sdiy] Programming Language Recommendation

[Spiros Makris]

>
>   There have been so many comments about "C++ big, clunky, all those
> libraries make stuff huge, no good for embedded".
> It looks to me like saying "C is too slow, because it has a library,
> which has sqrt(), and some of my team members really like sqrt()".


I think the argument that libraries make C or any other language "clunky"
isn't valid in most use cases; it is far clunker to have to embedded the
code of, say, the MIDI protocol in your (extremely) low level application,
making sure that every command happens exactly at the optimal place, in the
optimal way, following the flow of your programme. You will need ages to do
this and the result might be unreadable, unless you perhaps wrap it up
inside *a library*...
We're not in the 80's anymore, we actually have the cycles to spare on a
few bit shifts, or a function pointer or a class call, so we might as well
take advantage of that. In most cases those few ns won't make a difference
at all.
For example, after I coded my midi to cv module for the teensy, I decided
it would be good to rewrite the CV handling part in a way that lets me use
it in all future projects, regardless of hardware. You can find it here
<https://github.com/SpMakris/Gliding_CV_class>. I used 16bit unsigned
integers so that data types will be the same regardless of platform
(provided you include those headers, of course) and used a function pointer
for calling the dac output function. That way you can write whatever dac
handling routine you need and no matter how bizarre or complicated your DAC
is, the class just calls (*CV_output_function)(uint16_t DAC_value);
I guess it *might* have been a tiny bit faster to directly call the DAC
functions of HAL from within the library, but it's just a couple of
instructions more. At the end of the day, who cares? I'm not guiding
rockets to the Moon or supporting critical infrastructure, my bleeps and
bloops can tolerate a bit of delay.





On Wed, Dec 9, 2020 at 10:29 PM <sleepy_dog at gmx.de> wrote:

>
> Spiros Makris:
>
>
> > I have settled with C++ on my embedded projects and didn't have any
> > problems so far.
>
> That point I am most interested in.
> There have been so many comments about "C++ big, clunky, all those
> libraries make stuff huge, no good for embedded".
> It looks to me like saying "C is too slow, because it has a library,
> which has sqrt(), and some of my team members really like sqrt()".
> Just that nobody forces you to call sqrt() in an ISR, or at all.
> (I am sorry for having to use such a gruesome example more suited to
> Halloween than Christmas)
>
> If someone has a toolbox with a hammer in it that's really nicely
> shaped, beautifully colored, and is enticed to use the hammer when a
> small screwdriver is called for...
> well, it is hardly the toolbox that's at fault!
> It's about knowing your tools as well as your workpiece.
>
> Using e.g. newlib nano; disabling exceptions, RTTI; not using std
> container types that need dynamic allocation; being thoughtful with
> template usage, not going crazy with inheritance (generally a good
> idea), esp. not using calls to stuff with vtables in ISRs and such,
> ... are all things you can decide to do.
> std:: containers were still being avoided in many studios in game
> development in the mid 2000's, for performance / predictability reasons.
> See, they could choose. C library has no such things to begin with -
> that's hardly something that makes C faster.
> As for size - as long as you're not on a target where you really can't
> spare a single digit number of KB for the extra stuff getting linked in,
> I don't see the problem.
> Stuff you don't use is thrown out by the linker.
>
> Someone mentioned cryptic error messages.
> Sure. C++ easily takes the cake there, with any compiler I have seen.
> You'll get an idea of what they usually mean after fighting through it
> for a while, though.
>
>
> As for Python:
> It is funny you don't like it coming from C++, I also can't get myself
> to really get into Python.
> I do get its merits, one not small of them being that it's already
> installed frickin everywhere and if you'd like to do something on a
> small Linux system without installing anything else, and actually get a
> Turing complete, and not cryptic, awkward (no pun intended) syntax
> language... well, Python will be there.
> I've tried, a couple times... but I just don't like it. (and am not too
> fond of a type system-ish as an afterthought)
> But I'm particular, or was it peculiar, probably both - I hate Java's
> guts but really like C#, considered very similar by many - but in a
> bunch of important ways, they're not.
>
>
> > I don't want to use assembly ever again, but the experience of
> > learning it was indeed valuable and wholly recommended for anyone
> > trying to get into this field on a professional or academic level.
> It can sometimes still be useful for some snippets in embedded projects
> (just a bit of inline assembly)
> It can also help being able to read that when you step on instruction
> level through optimized code when debugging.
> (that said, my ARM asm chops are basic at best)
>
>
> - Steve
>
>
>
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at synth-diy.org
> http://synth-diy.org/mailman/listinfo/synth-diy
> Selling or trading? Use marketplace at synth-diy.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://synth-diy.org/pipermail/synth-diy/attachments/20201210/188e564a/attachment.htm>