311–320 of 536 posts
Earlier quoted context omitted.
To add to this, with a flathead screwdriver you can open a beer bottle, kill someone, make holes in a wall, nada all sorts of other useful things.
I'd probably prefer the philips to kill someone, but I've never killed anyone so what do I know :D
People who still write C, honest question: Why? C is full of quirks. From cryptic "undefined behaviors" to a type system that isn't really a type system (more like "size hints for the compiler"), the language doesn't feel easy to use/debug. Add to this CPP macros, a universally recognized bad idea, a clunky import system, and lack of a single reference implementation of the compiler/libC, and you have a language that…
"Although the first edition of K&R described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for…
they should simply use c++, like k&r did to compile their example code in their 2nd ed - see preface to book if you don't believe. i will never understand why C programmers get so upset about C++. of course, the latest revisions of C introduce some new features not in C++, but nothing really major. if you want good type checking, compile your C code with C++, and fix all the type errors you will get.
You're most likely not aware (as most C++ coders unfortunately), but this advice is useless today since it's not possible to compile current-time C code with a C++ compiler, the two languages have diverged too much since around the mid-90's.
A C++ compiler only accepts a "common C/C++ subset", but this subset hasn't been updated to include C features that had been added after ca 1995.
A better advice is to simply use the highest warning level and enable warnings-as-errors, this gives you mostly the same type checking as in C++ (minus the void* conversions, but that's how it should be since a void* is basically an "any*").
"Although the first edition of K&R described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for…
My career is in full stack web development but I program in C in my master's degree coursework and as a hobby. Every time I have to peel back a decade's worth of CSS to move a button on a webapp I daydream of moving to a career in C. Is the grass actually greener on the other side?
I don't think I would have appreciated it at different times in my career, but for me, right now, I'm loving every minute of it.
The biggest issue I've faced (beyond the obvious issues of getting anything to work at all), is how to organize the concepts.
The "Data-Oriented Design" folks have had a huge impact on that. Specifically, talks from Andrew Kelley, Mike Acton and the book by R. Fabian.
The second thing is registers. Just toss the HAL mess, pick up the Reference Manual and start poking registers. It's so much more enjoyable (and reliable) for firmware work.
I don't know about job opportunities as I'm running my own hardware business, but if you're feeling pulled in this direction, I highly recommend taking a closer look.
My career is in full stack web development but I program in C in my master's degree coursework and as a hobby. Every time I have to peel back a decade's worth of CSS to move a button on a webapp I daydream of moving to a career in C. Is the grass actually greener on the other side?
I'm an embedded Linux engineer and I love C and Linux in particular. However, I'm considering dipping my toes in non-embedded stuff for a while, particularly full-stack development and wondering if the grass is greener on the other side from me, haha!
Neither side is objectively better or worse, but having experience in both has changed how I approach problems.
Earlier quoted context omitted.
You're talking about something that isn't related to efficiency. Copy and pasting, macros, generating code -- none of these preclude producing an efficient solution. There is nothing in C++ that is inherently more efficient than C.
Except that more efficient solutions can be implemented much more practically? Solutions that you'd need to bend over backwards for in C?
Earlier quoted context omitted.
Microcontrollers exist. Their libraries are written in/for C. The programs running on them are small and need tight, efficient memory management. I also like the minimalist nature of the language itself. I get that for desktop applications, you usually want more integration with the operating system so you can say "I want a window here and a button here" rather than having to manually build the window from scratch, b…
Are the Arduino and ESP32 microcontrollers? Hint, might check their libraries/SDKs before answering.
You shouldn't assume I get to choose the platform I'm working on. That's not how it works where I'm at, and if (when) I do get to choose, programming language is unlikely to be near the top of the list of criteria.
Earlier quoted context omitted.
Don't think I'm too crazy but last time I checked: 1. Yes they are microcontrollers. 2. Yes they use C/C++. (check the libraries/SDKs, 1 layer under the hood it's all .h/.cpp files, and most of the arduino calls are just #defines)
So it isn't only C.
I don't understand why you're trying to cherry-pick like this.