271–280 of 344 posts
But the thing that would be better to do, in my opinion, may be like having LLVM with macros (including standard macros for dealing with differences of systems, and user-defined macros for your own use).
Earlier quoted context omitted.
I hope you were joking. This is just a "gotcha" quiz and not relevant at all.
I'm almost not. I made the point because this level of ambiguity and "do it yourself" is consistent throughout the language. I know why we still use C, but the use of C is inherently prone to security problems. C does not provide bounds checking by default, so it can be forgotten (Heartbleed) and the lack of either static checking, RAII or garbage collection (Not as a library e.g. Boehm) makes memory corruption all b…
In conclusion, the power given to Programmers by C far outweighs any of its perceived downsides in real-world scenarios.
Having written a conforming C compiler, at one point I knew everything there was to know about C (I forget details now and then, or confusing them with C++ and D). But knowing every engineering detail is not the same thing as knowing how to program in C effectively. It's like being the engineer who designs a Grand Prix car. It does not mean you can drive it faster around the track than anyone else. Not even close. Fo…
Earlier quoted context omitted.
> In some of our code, we would test the size of various types and structures on startup This is one of the things that C++ has actually improved a lot recently: doing this with static_assert is much nicer in terms of catching problems early... And yes, it's great for long-term maintainability.
C has had standardized static assert since the C11 spec was released. See [1] for instance. [1]: https://stackoverflow.com/a/7287341
Earlier quoted context omitted.
> My C/C++ code is as boring as possible. One advantage to being an older programmer is I don't feel any need to show off any more. I try to make it so obvious that anyone would look at it and think that's so simple, anyone could do it. It's surprisingly hard to write simple code. Any idjit can come up with Rube Goldberg code.
Though different people consider different things simple. To one a loop is fine, to another a map is a better choice.
Are you thinking more of JS or another functional scripting language than C/C++? C doesn’t have map, so it’s not an option, and in C++ it’s called something else.
In JS, I so wish that I could switch to functional constructs like map permanently, but map and foreach are much slower than loops, an order of magnitude or more for tight loops. I’m still forced to use loops in performance critical code, even if I consider map a better choice.
Coming back to C++ after having been in JS land for 5 years, C++ feels constantly difficult to use, and all the names for the functional primitives don’t seem to make intuitive sense like they do in JS.
uint32_t foo = 1; foo Here, I figured that foo would always be 0. Wrong. It was always 0 with GCC, but this is undefined in the spec and code like this can have a different value in clang. I actually had to make a security update to my little open source project because of this (although the code I wrote did not manifest the bug in an insecure way, even with clang).
Earlier quoted context omitted.
Except from the perspective of a pragmatics linguistic analysis, "I don't know" has a social context of "There's an answer, and I don't know it." In this case, a non-C programmer should answer "I don't know" to all of them. A person with a passing familiarity should answer similarly. A seasoned pro would be forced to answer the same. Making it a rather useless tool for distinguishing people who think they know C but…
>which is supposed to be the point of the exercise. I don't think that assumption is justified. Someone could say the point of the exercise is to illustrate that C is confusing.
Earlier quoted context omitted.
Except from the perspective of a pragmatics linguistic analysis, "I don't know" has a social context of "There's an answer, and I don't know it." In this case, a non-C programmer should answer "I don't know" to all of them. A person with a passing familiarity should answer similarly. A seasoned pro would be forced to answer the same. Making it a rather useless tool for distinguishing people who think they know C but…
>which is supposed to be the point of the exercise. I don't think that assumption is justified. Someone could say the point of the exercise is to illustrate that C is confusing.
Never once does the author mention that C is confusing, use the word confusing, or otherwise indicate that general idea. If you're getting that impression, it's your own reading into it. I'm not even saying you'd be incorrect, but that's not the author's intent, which was the basis of my comment.
Earlier quoted context omitted.
What would we write drivers in then if C was obsoleted?
Apple says the future is C++ and Swift. Microsoft says the future is a mix of constrained C++ (Core Guidelines), Rust and AOT C#. Google says the future is C++ and Java (as of Treble) on Android, with Go, C++ and Rust on ChromeOS and Fuchsia. ARM says C++ on mbed. GenodeOS says C++ and Ada. Newton, Symbian, Bada and BeOS used C++. C is married with UNIX, they were born to each other, other OSes have long followed oth…