Slashdot Mirror
Is IoT a Reason To Learn C? (cio.com)
itwbennett writes: Whether or not beginning programmers should learn C is a question that has been roundly debated on Slashdot and elsewhere. The general consensus seems to be that learning it will make you a better programmer -- and it looks good on your resume. But now there might be another reason to learn C: the rapid growth of the internet of things (IoT) could cause a spike in demand for C skills, according to Gartner analyst Mark Driver. "For traditional workloads there is no need to be counting the bytes like there used to be. But when it comes to IoT applications there is that need once again..."
Someone create a IOT language!
Ceci n'est pas une Signature !
and I not sure learning C will help much with that.
Pain is merely failure leaving the body
I heard this said before about phones, but eventually technology developed enough to allow mobile devices to have a strong enough processor. People are already too used to program higher-level and I see no reason why the same environments we have in our phones can't run on our fridges or boilers or ovens, therefore I do not think that people will use C.
Avantgarde Hebrew science fiction
IoT is a reason to learn a few things about IT security. Whether you plan to develop in the field or go into consulting, IoT means total job security in the IT-Security field for the foreseeable future.
Quite frankly, if you thought Microsoft is keeping security busy, just wait 'til IoT makes it big into the office space. You're looking at security holes and blunders you can't even imagine today! And every single of them are a sweet, sweet, 4 to 5 digit consulting gig!
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Android Things uses Java, and I'm sure other devices will use different languages (python, or something else that comes along). C is a nice to understand kind of language if you want to move libraries for Arduino to other platforms, but understanding any similar language will make that trivial.
Fair enough. You can always write C code in C++. But at the risk of being flamed, IMHO both are high-level languages. C++ is just higher level.
I recall reading (maybe in Stanley Lippman's primer book) an exercise question that asked why the language is called C++ and not ++C. Worth pondering.
If it weren't for deadlines, nothing would be late.
The language that pretty much invented to buffer overflow? Yeeeah, I think you might be right.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
If you're applying at a shop that does a lot of low level coding or coding on processor, memory and/or storage restricted platforms, if you're only experience is in Java or C#, I'd say your chances are pretty low. Walk in with a good practical grounding in C coding, I would imagine your chances go up. Not every shop is occupied by hipsters looking for keywords like "Python".
The world's burning. Moped Jesus spotted on I50. Details at 11.
If its imported as a product what code is going to be done? Branding over some device ready GUI?
Thats more an art skill for a web app?
Making your own IoT device in the USA? Whats trendy in 2017 for low level design work?
A US design team with the needed skills will work on that.
If the kit is sold, most of the work has been done.
If your making your own kit, you have the skills or paying a very smart person with the skills.
Domestic spying is now "Benign Information Gathering"
... that is the question.
It little behooves the best of us to comment on the rest of us.
... use BASIC:
10 get foxnews.com
20 refresh
30 goto 10
It little behooves the best of us to comment on the rest of us.
Swift is a language well-suited to byte counting, if that is a need - at this point because of the tremendous pressure to increase security on iOT devices I really think Swift could have massive uptake.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
In an ideal world, developers of this newly emerging industry would try to avoid the mistakes of the past. They would gravitate towards one of the "safer" low-level languages such as Rust or Ada instead of C.
Of course, from the news headlines it seems that IoT developers are already intent on recreating every bad security practice that's been described since the Morris Worm. So I'm not holding my breath.
MIPS ASM or GTFO
Grandpa, get off Slashdot. It's time for your Metamucil.
If it weren't for deadlines, nothing would be late.
Rust does anything in any space C can, but more safely.
Light IoT will always need languages that are very power cautious, but I see that bringing a rise of CUDA IoT, or even FPGA skills.
Heavy IoT will always be flavor-of-the-month.
Science & open-source build trust from peer review. Learn systems you can trust.
C was invented as portable assembly IIRC. If you cant sort out a buffer overflow then dont call yourself a programmer.
Real programmers see their job as making the computers job easy, not the other way around.
Career network security programmer here.
Absolutely of you're programming a device that connects to the internet, you should understand a bit about security and have a security mindset. If your device won't get regular updates, this is even more true.
Where does C fit in? It's unnecessary, if you just want to learn basic security best practices.
If you want to really understand how exploits work, and some advanced protections, you need to understand how your program and your data are arranged in memory, what actually happens in the hardware to when your asynchronous timer goes off, etc. For that, C is the language to learn. Java programmers know how to use Java. C programmers know how Java works, internally. The bad guys writing exploits are (typically) C programmers, they can defeat your PHP or Python program because they know how PHP and Python work internally.
You've always used languages with automatic garbage collection, so you mostly don't have to worry about freeing memory after you use it? Great. You don't know how and when memory is freed, and what happens when a hacker exploits a "use after free" to execute code that he's put into the variable you think no longer exists.
To be clear, I'm not saying that people need to *use* C to write secure software. I'm saying that if you *learn* C, you'll learn a lot that applies to advanced security knowledge in any language. Higher level languages are most commonly written in C; if you know how things are done in C you'll understand what your high-level language is doing behind the scenes. You'll understand your Ruby software much better if you understand how the same program works in C.
Just C on your resume without C++ will pigeonhole you as a code monkey. Learn C++ and you will also know C, which is essentially just C++ with subtractions. These days, it would be rare to encounter an embedded tool chain that does not support both C and C++, usually with the same compiler.
When all you have is a hammer, every problem starts to look like a thumb.
Have we fallen so far that we need a reason such as "IoT" to learn C?
Sad day.
Yeah, I don't think any modern IoT device has any programmer "counting the bytes". I used to count bytes, back when I had 4KB of memory, or 8MB of memory, or 20MB of disk space. I think you'll be hard-pressed to find any IoT device with less than a gig of virtual memory. Considering zero or near-zero graphics output, I think you'll be just fine with any language ever inventing.
My vote goes to turing, which I haven't seen in twe decades, but for which I have a school-age nostalgia -- I made a street-fighter-style game for high school, with stick-figure graphics!
Computers (and machines in general) were created to make the life of humans easier. Imho, a real programmer also remembers that fact.
Avantgarde Hebrew science fiction
Grandpa, get off Slashdot. It's time for your Metamucil.
Spoken by someone who probably thinks javascript is an awesome language.
Actually, no I don't. But it does have some awesome libraries, like d3.
If it weren't for deadlines, nothing would be late.
Yes, you should know C well enough to be able to read somebody else's code. At least. You may even switch to it for good, unexpectedly.
No, IoT-devices are a poor reason to start learning the language. By the time you are done, Moore's Law will make this devices powerful enough to run Ruby, Perl, and PHP, and you'll be able to go back to those...
In Soviet Washington the swamp drains you.
Real programmers? As compared to the untrue Scotsman?
Look around you and see what doubles as "programmer" today. Ask them how a stack overflow happens and why that is a problem. If I get a buck from you every time you get a blank stare and you get ten from me every time you get a sensible answer, your house belongs to me before the week is out.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
"If you cant sort out a buffer overflow then dont call yourself a programmer"
Several decades of severe network exploits show that a huge amount of software, commercial, free, open source, obscure, commonplace, whatever was written by people who can't call themselves programmers and used by those who don't have the 1st clue how to use it securely.
When I first got serious about computing, 2 decades gone, the common wisdom was that we had not choice but to keep on using the old (mostly very insecure) software because so much depended on it, it would be too costly to rewrite in more secure languages and in time it would all get fixed by better programming practices.
We are also only 2 weeks away from the 15th anniversary of Bill Gates' "Security is Job 1" e-mail
https://www.cnet.com/news/gate...
If we knew then what we knew now, how much damage would be caused by exploits, what it would cost to fix, remediate, the secrets exposed, the privacy intrusions, would that advice still hold or would we have been better off to say damn the torpedoes and rewrite all of it?
Pain is merely failure leaving the body
Then again if you claim to be a programmer who can't pick up python in a few sittings, you don't deserve the title.
- Michael T. Babcock (Yes, I blog)
Most mods will probably flag this as trolling. But I believe JavaScript is a great language for IoT. There are a few advantages of using JavaScript, it's actually very easy to get networking to work well and reliably. A programmer will be able to write front-end, server-side/less back-end and IoT back-end all in one language. The code will be portable across all these bases (not always needed, but some functions will be universal). There are now a proliferation of embedded devices that support JavaScript "natively" (ESP32, RedBear Duo, and many more). It might not be as fast as C, but it's fast enough. Here is a project I created using JavaScript at every level: https://www.hackster.io/anemoi...
Because https://www.youtube.com/watch?...
Buffer overflows can be very useful constructs when you handle them very carefully and properly. They can be used as the GOTO for very limited microprocessor's code.
Custom electronics and digital signage for your business: www.evcircuits.com
C or C++, coded appropriately, can best fit technical concerns with business concerns.
--
Marc A. Lepage
Software Developer
It seems likely that most IoT devices will rely on a central hub which leaves the devices as relatively dumb. The hub (or the cloud) side will likely be a less constrained environment so will use a higher level language.
The other factor is that the thing side has a manufacturing component so will probably be commoditized by Chinese manufacturers and relatively few jobs will exist outside.
Most of the arguments that embedded C developers had against C++ are obsolete. The language has been updated over the decades, and the compilers are much better. The C++ runtime libraries used to be a lot of black magic that was hard to get working in kernel space, and many kernels had to limit themselves to a subset of C++ in order to function (L4Ka, Symbian, and others). There are now lots of compilers that work reliably and lots of papers on how to get as many of the C++ features working on supervisor mode as you're willing to invest time into doing.
Disclaimer: I'm very much a C++ hater, and I'll never use it again even if that means I have to switch careers. But it's a purely subjective thing with me. Most of my old arguments against it no longer apply. These days I spend my energy attacking Python instead.
“Common sense is not so common.” — Voltaire
If you need a stronger microprocessor for a task use one. The notion that using buffer overflow or stack smashing or jumping into data segments with 'dynamic' code is something you should ever do is simply ridiculous.
Yeah... to get a 60Hz 1970s microprocessor to do something useful in 512 bytes of RAM you had to be creative... and it was expensive to go upmarket for a better CPU. But in the 21st century if you are using a buffer overflow to write code on purpose, the time you spend building and documenting and maintianing that... you should have just spent another nickle and got a more capable processor with more ram.
I've written code that popped the default return location and pushed a value that took me anywhere in the program I cared to go. https://www.youtube.com/watch?...
Just about any language can have a compiler written for it that writes code that meets the low-memory requirements. It helps if the programmer is intimate with the details of what language elements map to which machine code.
I do embedded C programming. With this said, I don't think that improvements to the tools are impossible - sure, I have to prevent buffer overflows myself at the present time - but it doesn't have to be this way. The key thing about embedded programming is that hardware designers are lazy. They want to do the least amount of work possible. So instead of making their hardware easy to program, they like to make it in a way that is easiest to them. So every data sheet contains all kinds of special exceptions to the rules that you the programmer have to take into account. And instead of supporting some fancy, easy to program in language, they do the minimum amount of work to make a C compiler work. (it's really minimal - you only need to map a few base instructions to opcodes on the hardware and you can bootstrap the C compiler).
One major issue is while every microcontroller or DSP generally has roughly the same stuff - various ports that do the same thing, the MAC instruction, usually a von Neuman architecture, usually interrupts and DMA - you basically have to scrape the datasheet for weeks to do something you've done before on a different microcontroller.
Where do you find these shops? I look on job postings and everyone is asking for the latest buzzwords it seems.
Yes, but shops want "senior" Python programmers. You can't claim to be that after a few sittings.
No. If that's your concern, simply PUSH the target address and RETurn to it. At least if your processor doesn't simply let you MOVe raw data into the IP.
There is exactly no reason to ever smash the stack to redirect the program flow UNLESS of course you do not have control over the program code, i.e. when you have to do pretty much what those who use that kind of exploit do. But then we're leaving the area of development and enter the realm of ... let's say repurposing.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
knowing how to program in C and how C works under the hood makes you a better programmer. Even if you don't program in C. That is reason enough.
Non sequitur: Your facts are uncoordinated.
Like it or not, C is still the defacto standard for embedded programming. If you're working in any where near bare metal your going to be using it. That may change but for now, if you dev for Internet of things and you don't know it, you're basically a script kiddie. Source: I'm an electrical engineer.
Am I the only one who has never heard of IoT?? Is that really a real thing? I gotta spend more time on the twitter or something to learn the cool stuff.
There's nothing BASIC can't do.. while that is generally true for programming languages in general, BASIC has a long tradition of bringing in house what for other languages are external libraries and turning them into commands that are intrinsics in the language. Take a look at all the modern flavors of BASIC and their built-in commands. If you can code it into a compiler it can be BASIC, baby!
Well, most systems use third party C compilers, gcc or keil or whatever. C is low level enough that the CPU doesn't have to know it's C anyway, it could be Fortran, Pascal, Ada, or whatever as long as it has a basic stack model. They're not supporting any language. Von Neuman isn't even required, there are many embedded systems that are Harvard architecture (separate regions for code and data) which C supports just fine.
Most buffer overflows weren't necessarily because of being sloppy in the original code, but because the code was copied so readily. Someone has a simple routine without all the necessary checks because it's not being used for anything very important, software that doesn't need to be secure, it's a one-off utility (maybe it converts postscript to PCL). Then someone copies that routine into another program, makes that a set-uid program, and poof you've got a security hole. First programmer says "it was not intended to be re-used", second programmer says "re-inventing the wheel is foolish!", and they blame each other.
Does "Python, PHP, SQL, C, and MOS 6502 assembly language" look good on a generalist resume? For example, I've used Python to make data conversion tools for games on 6502-based retro platforms.
Reducing compute times/memory usage by 0.1% in big data centers reduces the cost of electricity and cooling by millions.
Reducing compute times/memory usage in battery powered devices increases battery lifetime.
I view C++ as a better choice then C though, who can code a linked list from scratch more efficient then what they do? You get more abstraction power.
There are a lot of people who say they know C who can't handle some of the simple stuff in C, as I have seen in many interviews.
I started saying "I'm sorry that I will ask some very simple questions..." because I felt embarrassed asking someone with so much on-paper experience who is applying for a hands on development job to do such simple things. Then so many of them flub it. Now I'm wondering if my apologies that the question is "simple" actually ends up as an insult for someone who can't figure them out.
Computers (and machines in general) were created to make the life of humans easier. Imho, a real programmer also remembers that fact.
There are no technical reason a programmer cant create code that is good for humans (usable), and for machines (efficient).
The problem is when a programmer decides, or is forced to compromise on quality. That is the lesser programmer.
I dunno. There is still significant overhead with C++, which is a big problem with small devices (128KB of code for example). There's the issue of the linker not really figuring out how to share object code for templates to avoid typical bloat. There's the hidden operations behind the scenes that cause problems for novice programmers running out of space or wandering why their code is so slow. There really is no good way to make exceptions both fast and use little code space (a shame since I like them if used properly).
I do want to use a better-C-than-C. C with classes just for the sake of structuring code more coherently. C with better type checking rules. C where I can release a semaphore on any exit from a function. A stripped down C++ that more resembles Cfront without all the newer fluff.
Because the current crop of IoT programmers clearly don't know a thing about it, or just don't care, which is why IoTs are the largest DDoS attack army in history.
What's being discussed here are platforms that need features SWIFT simply doesn't have, like inline assembler to manipulate hardware specific features
That's not so; the assembly language of Swift is bitcode - which you can embed in Swift code for customized performance.
manual allocation schemes for shared memory (EG reserved blocks that are processed by hardware interrupts)
Although the link is not exactly that case you can use UnsafeMutablePointers for that purpose. Swift is not a garbage collected language, it uses ARC which is already deterministic as to when memory is allocated and released - but you can disable that for code and manually manage memory used.
To use SWIFT you'd need to develop entirely different custom libraries for each platform
Ask Apple how they support various ARM architectures...
No not everything is quite there, but Swift is moving rapidly and the underpinnings were built with the explicit goal that Swift COULD replace C as a language for any purpose, not just another higher level language that really can't apply for low level development. At this point the language is basically locked in but more features will be added over time, including stronger device programming support. That's why taking the time to learn it now means that by the time you understood it well you could probably start doing some hardware development with it... pretty sure LLVM at least and possibly Swift will be involved in some way at Tesla for example. When you are writing code that MUST be stable, like code that controls a car, C is just not going to cut it long term.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Sure. And if somebody has bothered to do the porting work and write a third party tool that uses a different compiler - and your project has the budget for such a tool - it's better. But it still isn't easy. You still end up reinventing many things.
Swift itself is also open source.
It also can be used as a full replacement for C in a way Rust cannot; see my response to someone saying Swift can't be used for device programming for examples. Rust is a nice language but it's just not as architected as Swift is for use across the space of devices like C is already.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Worth mentioning that a half-way decent string and buffer library will solve basically all buffer overflow issues. If you're using strcpy(), gets(), or even strncpy() (without knowing the pitfalls), then you're in trouble.
"First they came for the slanderers and i said nothing."
C is programming lingua franca. Anybody calling himself a programmer and not knowing C is not a programmer.
Before the mainstream software programming turned to be web programming, C was taught in every computer science university programme.
Not knowing C limits your competence to a small pond called web programming.
... Embedded is a reason to learn C though. And embedded and IoT do have some intersection/overlap. But I IoT itself is mostly a fad involving the slapping together of unsafe preconfection microlinuxes with unsafe overkill websevers/port 80 stuff and adding that to toasters and stuff that really don't need it and won't be used more than ~3 times unless by some bored teenagers wgo wants to screw up your homes heating or AC by surfing on shodan for some lonb forgotten default access to said IoT trinkets.
Bottom line:
You shouldn't do anything because of IoT unless it,s avoiding it like the plague (unless you're a hacker that is). OTOH If you want to learn embedded, C with assembler for the basics is the way to go.
Good luck.
We suffer more in our imagination than in reality. - Seneca
Sadly I run into that a lot, and I've interviewed a lot of people for low-level (i.e. bare metal) programming. Generally speaking, C is a fairly simple language, but in my line of work you better know damned well what various keywords mean and how they behave (like volatile) and know pointers backwards and forwards.
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
Hell, ask them what the stack is first, most won't have a clue. I used to ask developers (for C# positions) what the difference between a value and a reference type was. Still have not got a correct answer, eventually stopped asking the question. The problem is only going to get worse as they force more and more people to "learn to code" when they actually don't have the inclination. Cut and paste coders, the lot of them.
There are three kinds of falsehood: the first is a 'fib,' the second is a downright lie, and the third is statistics.
Its sometimes difficult to share template code, since a major point of templates is to reduce source code. Code that works for doubles cannot be the same code as code that works for ints. So how its not bloat. In C you would get exactly the same amount of bloat plus twice the source.
Just off the top of my head, a single template function instantiated with the same type arguments in two different compilation units produces two (identical) copies of the same code in the final executable.
I'm a minority race. Save your vitriol for white people.
I work at a company that makes chips for IoT, though in this case the chips are targeted at things like routers, switches, network security appliances and highly intelligent network cards. While C++ is supported, all of the stuff I work on is C. Our SDK is C. All of the vendor SDKs I've come across for dealing with different devices are written in C. Interfacing to C is fairly simple and well understood compared to introducing C++ in an embedded environment. Now the environment I deal with is either the Linux kernel or lower, usually lower since I work with bare metal most of the time.
C is used for a number of reasons.
1. The generated code is quite fast and fairly compact. With my experience with MIPS the output of the compiler is pretty close to hand-tuned assembly in most cases.
2. It's easy to deal with hardware registers in C. Hardware registers can be defined by volatile bitfields so a simple pointer can be used to access them.
3. There is no unintended overhead or hidden behavior. With C it is very much what you see is what you get. It doesn't do stuff under the covers.
4. Memory mapping data structures and things like that are very easy in C.
5. One is not dependent on things like a certain standard library. The amount of code needed for basic C support is fairly minimal. All you really need is a stack. I have plenty of code that does not have a heap.
6. Things like interrupt handlers are fairly trivial to code in C.
7. One can do interesting things using the linker with C code that are not really possible with most other languages. For example, I can easily link my code to execute at a particular address and generate a binary without any elf headers or any other cruft and there are interesting things that can be done with linker scripts.
8. There is no unexpected overhead due to the language. There is no background garbage collection that can run at some inopportune time. There's no extra code to do bounds or pointer checking to slow down the code or even get in the way.
9. Generally it is pretty easy to move between different versions of the toolchain. C generally doesn't change much.
10. C seems to resist bloat better than other languages, in part because it does exactly what you tell it to and nothing more.
Much of this can apply to C++ as well, though C++ requires a lot more overhead in order to properly support it due to some of the language features and C++ can hide certain things if you aren't careful.
That's not to say that things can't be written in high-level languages. There is plenty of flexibility once you get to something like a Raspberry Pi user-space program.
Arduino uses a subset of C++ but it's such a small subset that it might as well be C.
I write this as someone who has been writing embedded C code and assembly (98% C) for the last 20 years, though I have also worked on a few C++ projects as well. Most of this was device drivers, Vx Works, bootloaders (U-Boot and custom), bare metal applications and SDKs (dealing with high speed networking, 1, 2.5, 5, 10, 25 and 40Gbps) and some Linux kernel work and Arduino. I've worked with a variety of different CPU architectures (Intel, MIPS, ARM, PowerPC and more) including one that ran a functional programming language natively in hardware (the processor was physically incapable of running C code).
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
I have worked in one such environment. While C++ was nice there was still a lot of work needed to make it work properly, though this was 20 years ago for a large 100K C++ driver for OS/2 that ran in kernel space. The main thing was to not go overboard with C++ features and for performance reasons to keep the class hierarchy short (non performance-critical code didn't have this issue). This seems to be the exception rather than the rule though. Other than that project, everything else I have dealt with was in C and I don't really consider Arduino C++.
Properly written, the overhead from C++ was pretty minimal. The driver binary was around 1MB. The interesting part was that we had an equivalent driver for Windows NT written in C that was 360K lines of code with a significantly larger binary and the C code was much buggier and harder to work with. Compilers have improved significantly since that time but I recall that with the C++ code only one specific version of the compiler could be used, Watcom 10.0b as I recall. 10.0c, the updated version, could not be used.
Implementing the assembly code to support C is trivial compared to the minimal code required to support C++.
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
Properly written C++ actually has fairly minimal overhead from my experience, though in this case you want to limit what features you use in C++ and how you use it. Like you say, though, it's easy to get carried away and get a lot of bloat.
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
Two of the reasons for learning C are:
1. It is a good, general programming language that can allow you to produce efficient code.
2. You want to be a good programmer with a good understanding og the HW and the OS
I'm not convinced the growth in IoT thingies is other than an ephemeral fad. There will be a period with a lot of innovation, then it will settle down on the relatively minor subset of gadgets that are actually useful and wanted, and there will no longer be a lot of need for programming skills in that area. But the C language has already demonstrated its staying power (as have certain other languages like FORTRAN and COBOL to the surprise of many), and it will be relevant to know for years to come, no doubt.
K&R C could be considered portable assembly at one time (but a bloated one). Those days are long gone. Abstraction is for humans; abstraction is bloat for microprocessors.
There is no America. There is no democracy. There is only IBM and AT&T and DuPont, Dow, General Electric, and Exxon
> Just off the top of my head, a single template function instantiated with the same type arguments in two different compilation units produces two (identical) copies of the same code in the final executable.
Get a better head.
Failing that, get a better linker.
The linker can't help if the compiler in-lines the function, which it may choose to do regardless of programmer intention.
I'm a minority race. Save your vitriol for white people.
I love MIPS assembly. I actually have a page of MIPS assembly open at this very moment. In terms of programming, it's beautifully designed. The extension from 32-bit to 64-bit is pretty seamless. The only real gotchas are the branch delay slots, but I actually find it to be a nice challenge to fill those slots. (I always have .set noreorder set).
MIPS assembly is extremely clean, far cleaner than ARM, for example, and the online documentation is superb. I like the MIPS Architecture for Programmers Volume II. Volumes 1 and 3 are also useful. I have yet to find as clean of a document covering ARMv8.
Even the MIPS instruction encoding is quite clean and the CPU design makes it easy for vendors to add their own interesting instructions to coprocessor 2. For example, my employer has a bunch of encryption and hashing related instructions added there. ARM does not allow you to add your own custom instructions to ARMv8, for example.
MIPS is still used in many Internet appliances and home routers, though things are quickly moving to ARM. One advantage of the MIPS instruction is it very cleanly moved from 32-bits to 64 bits. With ARM that is not the case. AARCH64 is very different than 32-bit ARM. The differences are bigger IMO than the switch from X86 to X86_64. Another advantage of MIPS is that the licensing costs are quite a bit lower than for ARM.
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
Indeed indeed.
Or you can just use enough pokes until it does what you want.
While most of my work is for chips that are vastly more powerful than what is found in IoT devices I work on bootloaders and bare-metal programming. In some cases memory is a premium. With only a couple of exceptions, all of the work I have done has always been with C. Most small micros are programmed in C almost exclusively with a sprinkling of assembly.
C is very good for working closely with the hardware and in memory constrained environments. C code does exactly what it says. There is no hidden overhead. The runtime needed to run C code is pretty minimal. All it really needs to get going is often a few registers initialized and a stack and it's ready to go.
It works beautifully with memory mapped registers and data structures which are extremely common in this environment. There's even a keyword designed for this, volatile, that is not present in most other languages (or it does not do the same thing).
I can use a bitfield to define hardware registers and just map a pointer to the address of that register and use it. Mixing in assembly code is easy if it's needed, though generally I find that assembly code isn't needed very often.
It's also easy to generate a binary blob using C, a linker script and a tool like objcopy.
My experience has mostly been with 64-bit MIPS and some ARMV8 but it applies to most embedded processors. The output of the C compiler when optimizing for size (with the right options set) is pretty close to hand optimized assembly and often even better because the compiler does things that would make the code otherwise hard to read or maintain. The runtime overhead of C is minimal.
C's flexibility with pointers is also a huge plus. I can easily convert between a pointer and an unsigned long (or unsigned long long) and back as needed, or typecast to a different data type and pointer arithmetic is trivial. There is no hidden bounds checking or pointer checking to worry about. Many people say that's a bad thing, but when you're working close to the metal it can really turn into a major pain in the you know what. Master pointers and know how and when to typecast them. I've seen too many times where people screw up pointer arithmetic. I once spent several weeks tracking down a bug that showed up in one of my large data structures where I saw corruption. It turned out that some totally unrelated code written by somebody else in a totally different module was written by someone who didn't understand pointer arithmetic and was spewing data all over the place other than where it should be. He also didn't realize that when you get data from a TCP stream you don't always get the amount of data you ask for, it could be less.
I have been writing low-level device drivers and bootloaders for over 20 years and while programming has changed significantly for more powerful systems in userspace, for low level programming it has changed very little. My advice is to learn C and learn it well. Know what some of those keywords mean like static and volatile. Anyone who interviews in my group damned well better know what volatile means and how to use it.
C isn't a very complicated language but it takes time to properly master. It also doesn't hold your hand like many modern languages, which is why you often hear it is easy to have things like buffer overflows or stack overflows and it's also easy to shoot yourself in the foot. It doesn't have many of the modern conveniences, but those conveniences often come at a cost in terms of memory and performance.
The best book I've seen on the language was written by the authors of the language. It's not very long but it is concise and well written.
The C Programming Language by Brian W. Kernighan and Dennis M. Richie.
I have also worked on C++ device drivers. While the overhead of C++ itself is generally minimal, it depends that you use only a subset of C++ and you have to know what C++ is doing behind the sce
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
There is a practical reason, programmer efficency. If that programmer compromises, he can do more work.
Avantgarde Hebrew science fiction
The nice thing about C is that is as close to portable assembler as a language can get. It forces you to understand how computers and OSs work in order to become proficient, and in time your code will become better because of it - even when using other languages.
Of course, the ugly thing about C is that is as close to portable assembler as a language can get.
Agreed on all items. Another big selling point for C is that your code will likely run on all computer architectures out there with minimum modifications, and it is pretty much guaranteed to do so if you plan in advance about things like endianness.
So what is "the stack"? A core concept of C? Something the standard mentions in passing?
CLI paste? paste.pr0.tips!
This is a big part of the reason that Google has started looking for experience working on compilers for general programming jobs. It's pretty hard to get that experience without understanding how fundamental language concepts are implemented, even if it's just a one-month internship.
I am TheRaven on Soylent News
128KB is only a problem for C++ if you want exceptions and RTTI (which you probably don't in an embedded system). Embedded also has the massive advantage of being closed-world. This means that you can turn on LTO, which helps with code size a lot (or, if your toolchain doesn't support LTO, do it the old-fashioned way and #include everything into a single file for compilation). Multiple template instances tends not to be a problem because even a fairly primitive linker will throw them away, the bigger problem with C++ is that you can end up with versions of a template being instantiated for different types, yet with the same code (e.g. an int and a float instantiation for a vector - there's no reason for them to be different because the vector doesn't perform arithmetic on the types and only cares about the sizes). Modern optimisers are getting pretty good at spotting that these are identical code and combining them into a single implementation, but they could do better.
I am TheRaven on Soylent News
The template function is marked as externally visible, so the inliner will only inline it if there's a very large chance that after inlining the cost of the inlined version will be less than the cost of a call (when optimising for size, not speed - the heuristic is a bit different in the latter case). In this case, you'll get smaller code if you inline it everywhere and the linker will then throw away the definition entirely.
I am TheRaven on Soylent News
Hardware registers can be defined by volatile bitfields so a simple pointer can be used to access them.
Unless, of course, you have multiple registers with ordering constraints between them (e.g. write some data into one register, toggle a flag in another), because the volatile keyword in C does not give any guarantees of ordering between accesses to different volatile objects and the compiler is completely free to reorder the write to the flag before the write to the data.
Things like interrupt handlers are fairly trivial to code in C.
As long as someone else is writing the assembly code that preserves state for the interrupted context, prevents the interrupt handler from being interrupted, and so on, and then calls into the C code. And with those constraints, pretty much any compiled language is equivalent.
One can do interesting things using the linker with C code that are not really possible with most other languages. For example, I can easily link my code to execute at a particular address and generate a binary without any elf headers or any other cruft and there are interesting things that can be done with linker scripts
That's pretty much true for any compiled language.
There is no unexpected overhead due to the language. There is no background garbage collection that can run at some inopportune time. There's no extra code to do bounds or pointer checking to slow down the code or even get in the way.
The flip side of this is that you either do the bounds checking yourself (and often get it wrong, leading to security vulnerabilities) and end up passing it through a compiler that isn't designed to aggressively elide bounds checks that it can prove are not needed.
Generally it is pretty easy to move between different versions of the toolchain. C generally doesn't change much.
I can't tell from the Internet. Did you actually say that with a straight face? Even moving between different versions of the same C toolchain can cause C programs that depend on undefined or implementation-defined behaviour (i.e. basically all C programs - including yours given that several of the things that you listed in another post in this thread as really nice features of C are undefined behaviour, such as casting from a long to a pointer) are now optimised into something that doesn't do what the programmer intended.
I am TheRaven on Soylent News
You should only use C if your program has at least one of the following properties:
- It has extreme CPU efficiency demands; for example, it needs to use SIMD wherever possible and do so efficiently;
- It has strong realtime demands. E.g. you're rendering video or audio live with very low latency or are reading sensors and controlling something mechanical and therefore cannot have a garbage collector stopping the world even for a millisecond;
- It has extreme cross-platform requirements; you want to be able compile on many architectures.
Each of these can be a reason to pick C. However, IoT in general is not. Whenever you can, please pick a language with proper memory management. And if you must absolutely use C, consider writing only the parts of your application that absolutely need it in C.
When it came to selecting a programming language for writing a software synthesizer/sequencer, after extensive testing, there really wasn't any serious competition to C/C++/gcc w.r.t. auto-vectorization support and realtime characteristics. So I chose C++. And it is a world of pain. However, it is insanely mind-boggingly fast and even under heavy load will respond with sub-millisecond response times.
So FFS please don't pick C(++) unless you absolutely must.
0x or or snor perron?!
I love MIPS assembly.
Really? Branch delay slots (with 'unpredictable' behaviour if you put a branch in them), no complex addressing modes, weird instruction names (an unsigned add is the same as a signed add, except one will trap on overflow, because that's obviously what the difference between signed and unsigned means), special $hi and $lo registers because some instructions have an implicit destination. Half-arsed transition from a fixed-design pipeline so that some operations have hardware interlocks but some need some magic (and implementation-dependent) number of NOPs to work. Oh, and my favourite bit of MIPS, the superscalar NOP. When your ISA has a superscalar NOP, that's when you should realise that you've done something badly wrong.
In terms of programming, it's beautifully designed.
If you ever have to write ARM assembly, your head might explode if you think MIPS is beautifully designed.
The extension from 32-bit to 64-bit is pretty seamless.
The 'oh, by the way, if you don't sign-extend into the top 32 bits then you get undefined behaviour for any 32-bit arithmetic operation' thing is seamless? So any code that has to deal with 32-bit values ends up doing a left-shift by zero instruction (which makes the code totally readable - 'Hey, this looks like a nop, can we remove it?' 'no, it looks like a job, but we'll get garbage values if we remove it') at multiple points to enforce this invariant.
Even the MIPS instruction encoding is quite clean and the CPU design makes it easy for vendors to add their own interesting instructions to coprocessor 2. For example, my employer has a bunch of encryption and hashing related instructions added there. ARM does not allow you to add your own custom instructions to ARMv8, for example.
I'm guessing your employer is Cavium? Thank $DEITY that they're starting to produce decent ARMv8 chips and we can kill off support for their MIPS products in a few years. You might see this as a strength of MIPS, but to everyone else it's a massive weakness. Every MIPS vendor takes a version of GCC, hacks it up to support their extensions, and breaks support for other extensions in the meantime. They then can't get their patches upstreamed (the few that even try) and so their customers end up with an unmaintained dead-end fork. Worst ecosystem ever.
One advantage of the MIPS instruction is it very cleanly moved from 32-bits to 64 bits. With ARM that is not the case. AARCH64 is very different than 32-bit ARM.
I think that you and I have very different definitions of clean. MIPS quickly hacked on a 64-bit extension without thinking it through, AArch64 was the result of careful study of the intersection between code sequences that compilers like to generate and instructions that are efficient to implement. For example, a lot of the predication (really useful for assembly programmers, hard to implement in superscalar pipelines, hard to use for compilers) is gone, the user-addressable PC is gone (makes branch-prediction really hard on in-order pipelines) and so is store/load multiple (basically needs microcode). You keep all of the really useful bitfield manipulation instructions (no MIPS equivalent, and oh how I miss them when I have to deal with MIPS, which sadly I do on a regular basis), store and load pairs (including atomics on pairs) and so on.
Oh, and MIPSr6 is not backwards binary compatible with previous versions. All of the branch-likely opcodes were recycled as compact branch (no delay slot), you you need to patch your binaries if you want them to work.
I am TheRaven on Soylent News
Using strncat() has so many corner cases, I would recommend never using it. Too easy to make a mistake.
"First they came for the slanderers and i said nothing."
This SO answer is a pretty good attempt at explaining it:
https://stackoverflow.com/ques...
"Security best practices" would be to shitcan the entire idea of the internet of things as stupid and stop listening to marketing drones whose only motivation is to sell you some thing from which they can forever after farm data-demographic income.
-Styopa
If that programmer compromises, he can do more work.
In that case it doesnt matter what language the programmer uses, no language is idiot proof.
It was actually a rhetorical question. Standard C does neither specify nor require a stack or a heap, and memory allocation isn't specified in terms of those.
I'm only pointing it out because of the GP implying that knowing about "the stack" implies competence at C, which is far from true.
Or to put it differently:
$ grep -iEc 'stack|heap' c11std.txt
0
$
CLI paste? paste.pr0.tips!
I think we define compromise differently. If someone decides to give up on the quality of something, willingly, not because he can't, but because he has better things to do for the project, why is he an idiot?
Avantgarde Hebrew science fiction
I wrote a program a couple weeks ago that flashes a red light that alerts of a new Twitter post. Uses a RPi 3 and the program was written in Java.
Java has the ability to run threaded tasks easily which I wanted for polling the Twitter website. I could of used cron I suppose.
I assume C has something similar but I know Java and Raspbian has Java.
Sig. Sig. Sputnik
C was invented as portable assembly IIRC. If you cant sort out a buffer overflow then dont call yourself a programmer.
Real programmers see their job as making the computers job easy, not the other way around.
And one way a real programmer makes the computers job easy is making sure there code is as easy to work with for those who make updates after they are gone.
Absolutely untrue. I work in a group that does low-level coding on a processor with 48k of RAM and 1MB of storage.
Yes, knowledge of C is essential. But so is Python. I would say that I write about 10x more Python than I do C, partially because there's so little code on the actual platform and so much test code, analysis code and framework code that needs to be written to validate that small amount of embedded code.
So this whole dichotomy is totally nuts.
to really use it safely and properly you simply have to understand how computers work at the lowest levels.
I've done a lot of assembly myself (in the past, not so much these days!). That has been really helpful over the years as I can understand performance issues a lot better than someone who does not have that background...
I think though the computer industry has shown that even when someone truly understands the lowest levels of how computers work, they can easily write code that is not safe. I don't think there's any way past that other than an inherently safer language that still lets you access very low level parts of the system... Swift (and LLVM) is the first language/system I have seen that I think can take over for C.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I do want to use a better-C-than-C. C with classes just for the sake of structuring code more coherently. C with better type checking rules. C where I can release a semaphore on any exit from a function. A stripped down C++ that more resembles Cfront without all the newer fluff.
That's the basic point of Embedded C++. (Actually, that's not true, the real point was that in the '90s, companies making C++ compilers were having trouble implementing things like templates, and EC++ was an attempt to give them more time.) But if you disable RTTI and exceptions in the compiler options, avoid using anything that loves to use memory allocation (bye, bye, STL) in favor of your own fixed-sized memory pools, completely ditch unnecessary I/O crap (iostreams, locales), use the leanest run-time libraries (no floats in printf, etc.), and avoid going nuts with templates, the resulting subset of C++ can be quite lean. It also isn't hard to mix with plain C code as long as you declare things extern "C" when necessary.
It just so happens that mbed uses C++ this way, and it works quite well on small micro-controllers. The big thing that C++ does is to allow a class to be used as an API for a hardware device. All the details of a device's state are hidden inside its object, and similar hardware with different details can have a new class written for it with no changes to the code that uses it.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
C is awesome - that is reason enough to learn it
While serving as a teaching assistant for a compiler class back in the 80's, I had one student who was ordinarily pretty bright ask me "why do we need to learn how to write a compiler, since we already have a compiler?"
You've got it backwards. Yes, I do know x86 and the pertinent C implementations rather well. But no, since C abstracts those concepts away, there is a) no need to and b) it actually makes things less portable if you have implicit assumptions about what the machine has and does WHEN C ALLOWS YOU TO NOT CARE ABOUT IT.
So please tell me, given the code
int a, *b = malloc(sizeof *b);
What exactly is the advantage of thinking about `a` and `b` as "on the stack" and `*b` "on the heap"? I truly don't get it.
What is the problem with thinking about `a` and `b` as having automatic storage duration+block scope, and `*b` having allocated storage duration? It's THOSE TERMS that have well-defined semantics that EVERY C implementation (including those that put things "on the stack"/"on the heap") *has* to comply with. (That is apart from the fact that something you think is "on the stack" might well be NOT on the stack because it's "in a register", or got opimized out entirely, rendering your stack/heap categorization as a heuristic at best).
Learn some C. Make your programs more portable. You'll end up a better C programmer.
CLI paste? paste.pr0.tips!
Occasionally for a laugh I will click on a web link to a Yahoo Answers or other such site that asks "How does a computer work?" Invariably it's something like "This is the cpu, it does the thinking" and then moves on to the monitor and keyboard. So simplified even a kindergartener would roll their eyes. And yet the same site when asked about an automobile will mention internal combustion, pistons, gears, etc. For some reason, it's considered normal to treat computers like they're magic.
The problem I found with templates is that extra instantiations are *not* thrown away. They may be 99% the same but it doens't know that without actually comparing the code, and if it does know they're the same it is hard to keep that 1% difference and throw away the rest. You really need a C++ oriented linker with hins from the compiler, as opposed to a general purpose linker using name mangling (ie, binutils).
For instance, a template instantiated with "unsigned int" will result in slightly different code than one for "unsigned long".
In the past I have written templates that are nothing more than type casting wrappers around a basic type Ie, an collection of "void*" but then a template that lets you have a collection of any pointer type while still being strongly type checked.
This is essentially what "Embedded C++" is, it gets rid of the bloat or features that tend to bloat and then relies on programmer discipline after that. So not strictly C++, but highly compatible with it (and even more so with older C++ standards).
RTTI really is extra fluff that probaby never should have been added, in my opinion (and I used C++ before it was there). It's a high level language feature, and C++ really does hurt itself by trying to simultaneously be a high level language and a low level language.
I disagree, I think objects, templates and the static type system are core parts of C++. Exceptions and RTTI are nice features but not necessarily helpful to have in every C++ program.
“Common sense is not so common.” — Voltaire
Yup. Having been at a C house for some years now after having done C++ embedded systerms earlier, I am amazed at some of the early code had so little concept of encapsulation, functional coherency, extensibility, and so forth. Which is something you normally figure out very quickly in C++. Of course you can do this in C, but you need the experience on how to do it. In C++, once you have a class it's second nature to stick with that class when you have a newer variant of what you're interfacing with, maybe it's a subclass, maybe it's an interface class, but in C I see so many people just create a new API, throw in ifdefs, etc.
If the programmer is willing to compromise on usability and quality because there are better things to do, then how do you maintain quality control ?
Its just a matter of time until that 'better thing' he has to do is add another feature rather the bug check existing features.
At one job interview, I was asked to write a simple SQL query, so I turned to the whiteboard and wrote it down. It had a SELECT clause, a FROM clause, and a WHERE clause. I was standing there waiting to be asked to do something not immediately obvious to the SQL novice, and was slightly startled when they didn't.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Any programmer that thinks whitespace should be significant doesn't deserve the title.
You must wield C-x, M-c butterflies to get the badge?
Every end has half a stick.
If the compiler inlines the same function in two different compilation units, you'll have two copies of the function. That's what inlining means. There's nothing special about a template function in this regard.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
There's other reasons to keep inheritance trees short. Inheritance produces very close coupling between the classes involved, and if you're not actively taking advantage of inheritance (typically using polymorphism), don't use it.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Imagine an integrated kitchen, that keeps track of what you've got in the refrigerator and the pantry (perhaps through RFID chips in the packaging). You could have it generate grocery lists, make meal recommendations, all sorts of things. Lights that can turn themselves on and off to simulate someone doing things in the house to make it look occupied. Drawing a bath of desired temperature and depth without watching it. Having the dishwasher, shower, bathtub, and washing machine coordinate the need for hot water. I can think of lots of things I'd like the house to do, and which are technically feasible.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Right now I am playing a game called OpenRA. The game crashes for me sometimes when on the main menu and never crashes during gameplay. The game also suffers from a gameplay imbalance. Currently more effort is invested in adding these new balance feautres than in main menu ui stability. The balance is, imho, the "better thing". If the bug was fixed then we'd have a slightly more stable program on account of a crucial feature.
Ideally both things (ui bug + balance) should be fixed. Practically, time is limited.
Avantgarde Hebrew science fiction
In this particular case it was taking advantage of polymorphism in the main data path of a network driver (ATM networking, LAN emulation). The inheritance tree was quite short and kept to a minimum. This was because it could emulate different types of networks. Overall I don't think there was any additional overhead from C++ vs the same functionality written in C which would have needed function pointers instead of virtual functions.
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
My definition of clean is that you don't have to completely re-write assembly code when moving from 32-bit to 64-bit. On many other architectures, i.e. AArch64/X86_64 you do.
I'm not saying that MIPS is perfect. I'm not saying that there's anything wrong with AARCH64, but that it is radically different than 32-bit ARM, and I agree, the changes were very badly needed for the reasons you specify. In no way can you say that the transition from ARM32 to AARCH64 is clean, however. The code needs to be completely rewritten.
As for GCC extensions, to the best of my knowledge all of the Cavium MIPS extensions have been upstreamed and have been for quite some time. Unlike most MIPS vendors we actually have a sizeable compiler and toolchain team which has also been very active with AARCH64.
As for bitfield manipulation instructions they are there. Look up the ins (insert), ext (extract), bbit1 (branch if bit 1) and bbit0 (branch if bit 0) instructions. I use them extensively in my code. I know AARCH64 has similar instructions that are even more powerful.
Cavium actually had to teach ARM about atomic instructions, hence their addition in ARMv8.1 because the load linked/store conditional instructions don't scale. As far as I know we're still trying to get ARM to add transactional memory support (something we support in our MIPS chips) which is better than atomics on pairs. A big reason why they have the atomic instructions was because Cavium pushed hard for them because of our experience with chips with a large number of cores and scaling.
Also, the branch likely instructions had been deprecated for a very long time. Patching a binary is actually pretty trivial since the instructions just need to be replaced with the non-likely equivalent.
As for your hi/lo registers, that was done because the result exceeds what could be held in a single register. There's always the mul/dmul instructions introduced in MIPSv6 which does not use the hi/lo registers when you don't care about overflowing the target register. The hi/lo come mostly from the 32-bit days in order to handle a 64-bit result and the effect it had on the pipeline.
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
Hardware registers can be defined by volatile bitfields so a simple pointer can be used to access them.
Unless, of course, you have multiple registers with ordering constraints between them (e.g. write some data into one register, toggle a flag in another), because the volatile keyword in C does not give any guarantees of ordering between accesses to different volatile objects and the compiler is completely free to reorder the write to the flag before the write to the data.
That is what barriers are for to guarantee the ordering or the use of accessor functions. I'm not saying that volatile is a cure-all since it is not. It is a tool that needs to be understood. On many architectures one also needs to understand that a write to memory may not actually write to memory. For example, on MIPS a SYNC instruction is needed to flush the write buffer to guarantee that the data has been written to cache memory. On processors that are not cache coherent a cache flush is also required for data structures stored in memory that are accessed via DMA by hardware and a cache invalidate is needed before the hardware updates the memory before the CPU can read it.
Things like interrupt handlers are fairly trivial to code in C.
As long as someone else is writing the assembly code that preserves state for the interrupted context, prevents the interrupt handler from being interrupted, and so on, and then calls into the C code. And with those constraints, pretty much any compiled language is equivalent.
In C the context is usually fairly small compared to many other languages.
One can do interesting things using the linker with C code that are not really possible with most other languages. For example, I can easily link my code to execute at a particular address and generate a binary without any elf headers or any other cruft and there are interesting things that can be done with linker scripts
That's pretty much true for any compiled language.
Not really. Many compiled languages need a lot of support to handle things like memory management which C does not.
There is no unexpected overhead due to the language. There is no background garbage collection that can run at some inopportune time. There's no extra code to do bounds or pointer checking to slow down the code or even get in the way.
The flip side of this is that you either do the bounds checking yourself (and often get it wrong, leading to security vulnerabilities) and end up passing it through a compiler that isn't designed to aggressively elide bounds checks that it can prove are not needed.
Languages that do bounds checking and other hand holding generally don't work well on bare metal and in low-level (i.e. device drivers) environments. If you're relying on the language to catch your bugs then you have no business writing code in this sort of an environment. In this sort of environment a pointer often needs to be a pointer with no hand holding or the compiler or runtime trying to second guess the programmer. Compilers and languages do not understand hardware.
Generally it is pretty easy to move between different versions of the toolchain. C generally doesn't change much.
I can't tell from the Internet. Did you actually say that with a straight face? Even moving between different versions of the same C toolchain can cause C programs that depend on undefined or implementation-defined behaviour (i.e. basically all C programs - including yours given that several of the things that you listed in another post in this thread as really nice features of C are undefined behaviour, such as casting from a long to a pointer) are now optimised into something that doesn't do what the programmer intended.
Yes I did and on
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
These days I spend my energy attacking Python instead.
What's with all the python hate lately?
I own a company that does hardware and firmware, mostly for projects in the IoT space. We've had clients hire us to connect all sorts of dumb stuff to the internet. Many times you're using a chip that has a framework or stack that already exists; be it BLE, or Wi-Fi, or even Sub-1GHz (my personal favorite, it's the Denny's of wireless protocols). These frameworks are usually written in C. So while it's possible to incorporate them into a C++ project, usually it's just not worth the time or risk; it's easier just to leave it in C. The key to writing in C is to make it as human readable as possible. Code is written once, but read many times. So don't just use shitty variable names like "count"; use something that makes sense like associatedDevicesCount. That being said, for tight loops, i is just fine. It's also interesting how little customers care about security, even when our team brings it up. We're always trying to strike a balance. More security generally means more time during manufacturing (loading keys, etc.) or making the product harder to use. With manufacturing time going for (in US) about $1 per minute, we want to keep things moving. And clients hate dealing with customer support calls because the user can't get his miniblind controller to talk to his iPhone. C is also very popular for lonely devices - things that have to sit out there and just transmit information periodically, and are difficult to reset if the firmware goes haywire. I'd bet that 99% of iBeacons are implemented in C. Certainly the ones we've made are in C. All that being said, I'd like to try C++ on a new project; if nothing else for fun.
I can think of lots of things I'd like the house to do, and which are technically feasible.
So can I, but in my case it already does it: provide shelter, give me a private space etc. All this is a matter of taste, of course, but I don't want technology to do things for me, if it means that I will slowly forget elementary skills. A good example, in my view, is the ready-meal culture: what was once an obvious life-skill that everybody would need, is now regarded by some as nearly impossible. The absurd thing is that anybody can learn how to cook a very good meal with little effort and as fast as (or sometimes faster than) the time it takes to unwrap a ready meal, stuff it in the oven and heat it. People have given up the skill, and are now trapped in a situation where they feel they have to expensive, but poor quality food.
But to get back to the point - I wasn't so much talking about whether these products would become common or stay common, even after the fads have died down. It's like the pocket calculator - once they were among the most desirable gadgets in the world, and you could get them with many different features, and they are still popular - but they have settled down to a very limited number of designs; laptops, phones and tablets fulfill most of the needs now, and most pocket calculators are limited to the very basic arithmetics. Same with IoT: I'm sure we will see loads of gadgets that do something that isn't actually all that useful - like being able to turn the heating up or down while you're away from home - but then, when they start breaking, most won't be replaced. The ones that turn out be of real value to people will probably be of a few, relatively simple designs, and they will be robust and/or cheap and easy to replace. My guess is that there will only be a relatively small need for developers in that industry in the long run.
Sounds to me like good C++ style.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes