8 ms·
Important reminder just in the Preface :-) Takeaway #1: "C and C++ are different: don’t mix them, and don’t mix them up"
by belter 2y ago
Important reminder just in the Preface :-)
Takeaway #1: "C and C++ are different: don’t mix them, and don’t mix them up"
- pjmlp 2y agoSpecially relevant to all those folks that insist on "Coding C with a C++ compiler", instead of safer language constructs, and standard library alternatives provided by C++ during the last decades.
- Spivak 2y agoI mean as long as your goal is specifically to do that I think it's fine. Using a C++ compiler to compile a C program isn't that rare.
- com2kid 2y agoPerfectly valid to do if you need to interface with a large C code base and you just want to do some simple OO here and there. Especially if you cannot have runtime exceptions and the like. This is how I managed to sneak C++ into an embedded C codebase. We even created some templates for data structures that supported static allocation at compile time.
- f1shy 2y agoWhat would be an example of "simple OO here and there" that cannot be done cleanly in plain C?
- raluk 2y agoRAII
- f1shy 2y agoIs RAII Object orientation? I thought it was an idiom of C++ by Stroustrup.
- runevault 2y agoIt doesn't necessarily have to be OO no. Rust uses RAII and it uses traits instead of traditional OO style inheritance etc. You do need something like destructors/drop trait for it to work as far as I know though.
- tjoff 2y agoThe killer feature of RAII is when combined with exceptions. But sneaking in exceptions in an embedded C project isn't something I'd encourage or recommend. C++ imo doesn't offer anything compelling for the embedded usecase. Especially not considering all the footguns and politics it brings. You can of course be strict and diligent about it but if you are you are pretty much just writing C anyway. Better to do it explicitly. Allowing the use of the C++ standard library has been one of my biggest regrets (not that it was my decision to make, I fought it).
- AlotOfReading 2y agoC++ offers lots of compelling things for embedded use cases, like enum classes (finally fixed in C23), constexpr, std::optional, namespaces, and atomics/generics that are much smaller dumpster fires. There's an effort to extract the good parts and make it work for embedded use cases or even bring them into C. Khalil Estelle on WG21 has been working on an experimental, deterministic runtime for exception handling, to give one example. Constexpr is an example of the latter that's now showing up in C23.
- tjoff 2y agoI don't disagree, but these are in the ~2% convenience at most. With the huge baggage of including C++ in a project. The cost of learning C++ easily outweighs all those benefits. If you happen to have a proficient C++ team (that actually know embedded), go for it!
- AlotOfReading 2y agoSpeaking more broadly than just the std implementation, but result types like optional shouldn't be a 2% convenience, they should be used in most function calls that return errors. Rust is the obvious example here.
- tjoff 2y agoIf you argue for Rust I'm all for it, arguably much less of a learning curve than C++ too.
- adamrezich 2y agoNamespaces, methods.
- f1shy 2y agoNamespaces is not object orientation, is it? Am I missing something? You can place functions (methods) inside of structs in C23, can't you?
- staunton 2y agoOn a high level, "object orientation" means you think of your code as representing the state and interactions of objects. You can equally well do this in assembly. If you think of some namespace as a "singleton object" then that's what it is. I guess what you're really asking is what are the best or most common ways to do OO in C?
- f1shy 2y agoOh. I learned that object orientation is primarily a way to structure data and code, such that the data is encapsulated with the code that works on it, in so called objects. So an Object is the Data, plus the functions that work on the data, an ensure that some invariants are kept. In OO parlance, that code gets executed by sending messages (calling methods). Where can I find something about objects being "think of your code as representing the state and interactions of objects" honesty totally new to me. So no, certainly I'm not asking ways to do OO in C. But it seems to be more definitions of object orientation as I thought...
- int_19h 2y agoThere's no clear definition of what OO is, so the best you can do pragmatically is look at mainstream languages that are broadly recognized as OO and try to deduce the commonalities. If you do that, you'll notice that, for example, encapsulation is not a part of that de facto definition, because languages like Python and (until recently) JavaScript lack it, despite being considered OO. Indeed, the only two things that appear to be consistently present in all OO languages are: 1) some notion of object identity as distinct from object state, and 2) runtime polymorphic dispatch.
- bobmcnamara 2y agoTemplating on pixel classes so that a blitter builds all supported pixel paths separately and inlines them. Yes you can do it less cleanly with macros or inline functions. But you can't do it performantly with struct and function pointers.
- deleted 2y ago[deleted]
- cozzyd 2y agoCRTP?
- com2kid 2y agoYou can do anything in C that you want to. Of course one can make v-tables and all of that, and even do inheritance. But having the "class" keyword is nice. Having built in support for member functions is nice. Sometimes a person just wants the simplicity of C++ 2003. (In reality I was working on a project where our compiler only supported C++ 2003 and we had a UI library written in C++ 2003 and honestly pure C UI libraries kind of suck compared to just sprinkling in a bit of C++ sugar.)
- throwaway2037 2y ago> You can do anything in C that you want to. How about destructors?
- com2kid 2y agoYou can obviously build any runtime system you desire in C, including one that parses and executes C code with additional features added in. The wisdom of doing this is questionable. Though I've actually seen macro systems that do things akin to destructors, although less automatically.
- nerfnet 2y agoSurely you are aware that C++ destructors are essentially made in C.
- pjmlp 2y agoYeah, but one should provide C++ type safe abstractions on top. Just like one doesn't use Typescript to keep writing plain old JavaScript, then why bother.
- flohofwoe 2y agoFunny because for a long time the Microsoft MSVC team explicitly recommended compiling C code with a C++ compiler because they couldn't be arsed to update their C frontend for over two decades (which thankfully has changed now) ;) https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/ https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an...
- rdtsc 2y agoThat thing always baffled me, this huge company building a professional IDE couldn't figure out how to ship updates to the C compiler. > it is hard to say no to you, and I’m sorry to say it. But we have to choose a focus, and our focus is to implement (the standard) and innovate (with extensions like everyone but which we also contribute for potential standardization) in C++. I mean, yeah if it came from a two member team at a startup, sure focus on C++, understandably. But Microsoft, what happened to "Developers! Developers! Developers!"?
- Jtsummers 2y agoIt's not baffling, it's remarkably consistent. They implemented Java as J++ and made their version incompatible in various ways with the standard so it was harder to port your code away from J++ (and later J#). They implemented things in the CSS spec almost exactly opposite the specification to lock people into IE (the dominant browser, if you have to make your site work with 2+ incompatible systems which will you focus on?). Not supporting C effectively with their tools pushed developers towards their C++ implementation, creating more lock-in opportunities.
- AlotOfReading 2y agoFunnily enough, the intellisense parser does support C syntax because it's using a commercial frontend by edison under the hood. MSVC's frontend doesn't.
- pjmlp 2y agoIt was on purpose, Microsoft was done with C, the official message was to move on to C++. The change of heart was the new management, and the whole Microsoft <3 FOSS.
- jpcfl 2y agoBjarne should have called it ++C.
- card_zero 2y agoBecause people choose to use pre-increment by default instead of post-increment? Why is that?
- jejdjdbd 2y agoWhy would you use post increment by default? The semantics are very particular. Only on very rare occasions I need post increment semantics. And in those cases I prefer to use a temporary to make the intent more clear
- card_zero 2y agoPeople seem to mostly write a typical for loop ending with ; ++i){ But I write ; i++){ and seeing it the other way round throws me off for a minute, because I think, as you put it, why would you use those very particular semantics? But I guess this is only a semantic argument.
- johannes1234321 2y ago> why would you use those very particular semantics? The difference is that i++ has to keep a copy to the original around as the return value is the pre-increment value, while with ++i that isn't needed as the resulting value is being returned. In the for loop that shouldn't matter as a) for an integer it is essentially for free (it is just reordering when the relevant register is set) and b) that value is hopefully optimized out anyways by the compiler, however as there are cases where it matters some people prefer the ++i style, some just think it looks better.
- layer8 2y agoIn C++ the semantics can differ, in that copying an object for post-increment might require a memory allocation internally (for example in the case of a BigInt class), which may fail and throw an exception. For consistency, using pre-increment by default and unless you really need post-increment, is a good habit.
- f1shy 2y agoA couple of months ago, in the company I work, there was a talk from HR, where they explained how to make a good CV (the company is firing lots of people). She say: "if you have experience in programming C, you can writing just that, or, if you have lots of experience in C, is customary to write ``C++ Experience'' " Sooo... yeah... I should definitely change company!
- jasode 2y ago>Takeaway #1: "C and C++ are different: don’t mix them, and don’t mix them up" Where "mixing C/C++" is helpful: - I "mix C in with my C++" projects because "sqlite3.c" and ffmpeg source code is written C. C++ was designed to interoperate with C code. C++ code can seamlessly add #include "sqlite3.h" unchanged. - For my own code, I take advantage of "C++ being _mostly_ a superset of C" such as using old-style C printf in C++ instead of newer C++ cout. Where the "C is a totally different language from C++" perspective is helpful: - knowing that compilers can compile code in "C" or "C++" mode which has ramifications for name mangling which leads to "LINK unresolved symbol" errors. - knowing that C99 C23 has many exceptions to "C++ is a superset of C" : https://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B#Constructs_valid_in_C_but_not_in_C++ https://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B...
- accelbred 2y agoC++ can seamlessly include C89 headers. The C library headers for libraries I write often include C11/C99 stuff that is invalid in C++. Even when they are in C89, they are often incorrect to include without the include being in an `extern "C"`.
- nuancebydefault 2y agoExtern "C" around the prototypes is mandatory, otherwise your linker will search for C++ symbols, which cannot be found in the C libraries you pass it.
- accelbred 2y agoNot only prototypes but typedefs with function pointers as well.
- Conscat 2y agoClang supports C11 - 23 in C++, as well as some future C features like fixed-point integers. The main pain points with Clang are just the fundamental differences like void* and char, which don't typically matter much at an interoperability layer.
- MathMonkeyMan 2y agoMy brief foray into microcontroller land has taught me that C and C++ are very much mixed. It's telling that every compiler toolchain that compiles C++ also compiles C (for some definition of "C"). With compiler flags, GCC extensions, and libraries that are kinda-sorta compatible with both languages, there's no being strict about it. _My_ code might be strict about it, but what about tinyusb? Eventually you'll have to work with a library that chokes on `--pedantic`, because much (most?) code is not written to a strict C or C++ standard, but is "C/C++" and various extensions.
- rramadass 2y ago> because much (most?) code is not written to a strict C or C++ standard, but is "C/C++" and various extensions. Absolutely true. I generally insist on folks learning C and C++ interoperability before diving in to all the "Modern C or C++" goodness. It helps them in understanding what actually is going on "under the hood" and makes them a better programmer/debugger. See also the book Advanced C and C++ Compiling by Milan Stevanovic.
- emmelaich 2y agoIf you want a language with a great C FFI, C++ is hard to beat!
- sim7c00 2y agocan't believe so many people are arguing against this honestly. you don't mix them in the sense the author means. I take it these people didn't read the paragraphs this was the 'takeaway' from. For example, the primary reason for the sentence seems to be from the text: "Many code examples in this book won't even compile on a c++ compiler, So we should not mix sources of both languages". It's not at all about the ability to use c libraries in c++ projects or vice versa :S.... c'mon guys!
- deleted 2y ago[deleted]