[sdiy] Programming Language Recommendation

[Tony Sidaway]

When I started learning C in the late 1980s Koenig's monograph "C traps and
pitfalls" was very useful. I'm not really sure it would be so much use now
as the language has changed somewhat under the influence of standardisation
and convergence with popular features from other languages.

C++ is a pretty good choice for low powered processors, and frankly I don't
see any great advantage to C in such tightly constrained environments when
we can see that Arduino sketches, written in C++, scale quite well right
down to all but the smallest 8-bit AVR chips. If people are squeezing a
bootloader, a C++ runtime and a useful Arduino sketch into 8kb of flash
(just 4192 AVR instruction words) in the ATtiny85 used in Digispark boards,
I don't think C++ can be that much of a liability.

On Fri, 4 Dec 2020, 14:22 Steve, <sleepy_dog at gmx.de> wrote:

> If you want to go the C route, you might find this useful. Although this
> is for an outdated language version, the basic pitfalls still apply.
>
> http://literateprogramming.com/ctraps.pdf
>
> Some of that of course also applies in C++ as they are closely related.
>
> If you actually do already know C++ well, there's really nothing to be
> said against using a sane subset of it on bare metal "MCU" targets.
> You need to know what (not) to use and do, of course. (I *could* elaborate)
> Programming "OO" in the way it was taught in Java intro prog class at uni,
> probably not.
>
>
> I hardly ever bother doing anything in pure C these days, unless it's for
> a really small target.
> For reference, on a stm32 with 8 KB RAM and 64 KB flash, I might still use
> C++ and can get a decent amount of functionality in there.
> I don't remember a project, but 4K / 32K, I wouldn't be afraid either.
> (but may use still less of C++)
>
> I make more or less extensive use of features that need at least C++11,
> preferably C++14, if not 17, and which current C does not offer.
> The number of contexts where "constexpr" can be used increased from
> verison to version of what today some call "modern C++",
> and this particular feature alone has tremendous impact on my "embedded"
> projects - it is the savior from the much hated preprocessor macro
> insanity. (I still use that, but in much fewer, special contexts)
> Compile-time computation and real constants, that's what almost tips me
> over to using the word "beautiful" w.r.t. the C++ language. In a limited
> context, mind you :D
>
>
>
> - Steve
>
>
> *Von:* "Shawn Rakestraw" <shawn at epicpoolsga.com>
> Thanks Jay, I actually installed a VirtualBox with Ubuntu tonight and
> started learning C. It is a lot like C++. Hopefully I can pick up on the
> basics of it pretty quick. At the moment I have been a little confused
> about the * and ** next to variable names. Also the & variable names. I
> found some resources about it and realize they indicate pointers or
> something. I'm just not following the reason to have a pointer instead of
> the variable. I'm sure it will become clear as I continue to learn.
>
> On Thu, Dec 3, 2020, 3:11 PM Jay Schwichtenberg <jschwich53 at comcast.net>
> wrote:
>
>> I was an embedded/bare metal HW/SW engineer and will say working with
>> embedded ARM uCs C.
>>
>> C++ usually complicates things and is overkill for run of the mill
>> embedded stuff. Don't know if it is still true but at one time the C++
>> libraries had a lot of bloat and took up a lot of storage. I've also found
>> C++ harder to debug when people start overloading and abstracting things.
>>
>> If you do need to run object based code you can in C. Take all the data
>> for an object and put it into a structure and then pass a pointer to the
>> structure around through the code. This is more or less the equivalent of a
>> 'this structure' that objects have in C++. The data is isolated to a single
>> object and just use a new structure with different data for another object.
>> Also follow C++ and make you own constructors and destructors to setup and
>> shutdown things.
>>
>> Jay S.
>> On 12/2/2020 6:45 PM, Shawn Rakestraw wrote:
>>
>> Please don't go into extreme detail (unless you really want to). I ask
>> too many simple questions and I feel bad that everyone spends great amounts
>> of time with it.
>>
>> I am thinking about programming ARM chips like the STM32 for something
>> like Braids. I know that I will not be making my own Braids module anytime
>> soon, but I would like to start thinking about the language I need to
>> learn. I know the most about C++. I also realize that my question may be
>> better asked as what libraries should I load / study up on.
>>
>> Thanks guys/gals
>>
>>
>> _______________________________________________
>> Synth-diy mailing listSynth-diy at synth-diy.orghttp://synth-diy.org/mailman/listinfo/synth-diy
>> Selling or trading? Use marketplace at synth-diy.org
>>
>> _______________________________________________
>> 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
>
> _______________________________________________ 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
> _______________________________________________
> 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/20201204/cfb94634/attachment.htm>