C++ and stuff on embedded processors, again

Send the political posts to comp.arch.embedded too, they love that s*it.

Simpler explanation: most arduino coders are beginners, writing simple applications. That type probably won't have the experience to appreciate C++'s virtues, nor will they have the inclination to spend the time to become a C++ language lawyer - and the FQA will, rightly, put them off.

Well it's fine on a PC / rPi of course, since the RAM is huge and there is memory management and virtual memory. You would not use it on a PIC. There is a middle ground like perhaps the cortex chips with 64 or

On a sunny day (Sun, 1 Oct 2017 08:29:43 -0400) it happened bitrex wrote in :

sigh. Never forget seeplushplush was created to treat things as 'objects' This is an abstraction that puts overhead on any code, as computer code has nothing to do with objects, but is sequential.

It was created for kids that would live in a world playing with little wooden cubes, 'building' something. Selling the illusion that using 'object oriented programming' was EASIER. It is NOT. Even worse is overloading, now the kids no longer have to be aware of what they put on each other. Imagine building a bridge without ...

So it is dangerous crap by design, and has lead the world into ever more bloated, slower, inefficient, un-understandable annoying, dangerous, ....

One argument was that it would make it easier for larger projects to be constructed.. The largest multi-programmer contributed project today is Linux, and luckily Linus does not want seeplushplush part of the kernel.

The thing that pushes it all is sales, sales of more bloated languages, one born every month I think, needing more bloated hardware to to nothing new, and even if new, something nobody needs. Like 3 D s*it hanging from your head. Ever faster processors needing ever more power bringing in ever more money. The symbiosis between bad programmers bad languages and hardware manufacturers: It sells.

People used to call that 'snake oil'.

So I am leaving it at this. WE Hello world In the next version of WE we will fix formatting.'

"Hey, can you write in White Elephant yet?"

Oh, yea, new compiler, cool.

I was reading there is (or they just gave up) a company that trained anyone to be a website developer in 3 month. I know some websites that it looked like they worked on.

I took some Arduino seeplushplush code for some sensor chip and rewrote it in in C. Was a lot more readable.

Big deal. No matter how many "improvements" they make, they'll *never* beat K&R C. I refuse point-blank to use anything else.

On a sunny day (Sun, 01 Oct 2017 15:25:09 +0100) it happened John Devereux wrote in :

Indeed these days .. is Pi and embedded system? sure, ... You are absolutely right... I ONLY program PICs in asm for that reason, having about 12 kB code space and 512 bytes RAM needs its own tricks. I only ran out or code space and RAM once:

The way it now goes with Raspberies that have 4 cores > 1 GHz.... build in WiFi, what not, I expect to see those more and more in embedded systems. Still not real time, ultra low power consumption, and ultra low weight though, like the PIC!!

That malloc() issue did happen to me just a while back when I wanted to change that xgpspc navigation program to HD, in that code screen size is just a variable, but libjpeg that it uses, uses the _stack_ for memory, at 4 k resolution you get a stack space error in Linux, and have to set stackspace to unlimited on the command line. So I decided to rewrite my code interface to libjpeg with malloc(), resulting in using a list of pointers that all needed to be malloced and freed.. a websearch found the solution on stackoverflow.com, very helpful site.

You wrote your own newsreader?

Nice stuff. As a non-programmer, I just want to get engineering done and don't care how windows-ey it looks. Programming is boring to me.

Everybody these days is running Python, which to me looks a lot like Basic,

print 'Hello, world!'

but with more stuff hidden, and really weird data types. I suppose I could install and learn Python, but PowerBasic works for now, and is actually a compiler.

Nowadays the language, per se, isn't a dominant factor. Far more important are: - the libraries - how well the libraries play/interfere with each other - whether you can get proficient staff

Naturally the language plays a part in /enabling/ all that.

The Basic concept was to have most everything internal to the language, and not need libraries. In PB, I can do TCP/IP or UDP or sorts or file/string functions without externals. The HELP is good enough that I don't need to study man pages of library functions.

My embedded guy uses plain C, and other engineering and test people use mostly Python with jillions of standard and home-made libraries, with elaborate library management schemes. I'm just a circuit designer, so I want to do math as simply as possible.

Add to that: - Support of libraries written in other languages - Ability to link to - and interoperability with - 3rd party code which was not written with this particular environment in mind.

In "modern C++" you can do the memory management in software by writing your own custom allocator that conforms to the "Allocator" concept/template and then use the overrides of "new" and "delete" as usual. And most of the standard library templates like std::queue, std::vector are written such that you can "plug in" any custom allocator you like that exposes the proper API, you don't just have to use the default implementation.

If one's willing to accept a few restrictions on what type of object can be allocated into the pool on the heap then a custom allocator for an 8 bit architecture doesn't have to be particularly sophisticated, but you're already limited by the available heap size, anyway.

Combining it with a smart pointer and using it appropriately ensures that you'll never leak pool memory. The ideal of later versions of C++ for desktop architectures is that explicit user-called or "naked" new/malloc and delete/free are essentially forbidden; resource acquisition and release should ideally always be automatically managed.

Historically far too many people attempt that, frequently with sub-optimum results -- especially when several independent libraries are combined into one executable. Been there, got the bite marks :(

The former /ought/ not to be important: if everything else is right then inter-language calls will be a rarity.

The latter is very important, and is what I /intended/ to imply in my "libraries not interfering with each other" point. Historically C/C++ is abysmal in that respect.

Not really, even folks who surf both groups redirect politics here, not there.

On a sunny day (Sun, 01 Oct 2017 10:57:04 -0700) it happened John Larkin wrote in :

Yes, in 1998 or so... There was no 'FreeAgent' for Linux, so I wrote 'SecretAgent' for it, basically same functionality, later renamed to NewsFleX;

I cannot separate software and hardware, every chip I need has either SPI or I2C interface. Every function I need needs programming, even a simple LCD display needs code. I like programming, as the parts (lines of code) are free.

I have looked at it, Pythons.... Elephants, Pigs, all the same to me :-)

Yes having a BASIC compiler is nice. I have an old 8052 system with MCS-BASIC interpreter in ROM, it still works. But gcc (C) is portable to almost any platform.

PIC asm is also fun, easy once you have written some libraries. And then there was Verilog... FPGA.

Here is air pressure over last 24 hours (just type 'F'):

Here's my plot of indoor and outdoor temps at the cabin in Truckee.

There's someone up there now (our pet care lady) so the heat is on.

I did the acquisition hardware as a little PCB, talking serial to a refurbed Dell PC. I use good calibrated platinum RTDs, and the software is PowerBasic. I can also control the heat (software thermostat!) remotely, so we can warm up the place before people arrive. I can also replace code remotely, or run any Windows command line. All the internet stuff is through shared Dropbox files.

in

m:

dl -lXt

vigation, steering, auto-pilot, many things more:

mote via ssh from AMD PC:

cretAgent' for it,

I or I2C interface.

code.

rks.

more.

I see this

"that's the joke" ;-)

Well, what happened? Can't leave everyone in suspense like that...