4 ms·

> What additional code? All the code that you need in order to support smart pointers, templates, move/copy semantics, exceptions and so on. To paraphrase some

by alxlaz 9y ago

> What additional code? All the code that you need in order to support smart pointers, templates, move/copy semantics, exceptions and so on. To paraphrase someone whose opinions you should take far more seriously than mine, you can't just throw Stroustrup's "The C++ Programming Language" on top of an x86 chip and hope that the hardware learns about unique_ptr by osmosis :-). There used to be such a thing as the sad story about get_temporary_buffer ( https://plus.google.com/+KristianK%C3%B6hntopp/posts/bTQByU1iWGK https://plus.google.com/+KristianK%C3%B6hntopp/posts/bTQByU1... -- not affiliated in any way, just one of the first Google results). The same goes for all the code that is needed to take C++ code and output machine language. In my whole career, I have run into bugs in a C compiler only three or four times, and one of them was in an early version of a GCC port. The last C++ codebase I was working on had at least a dozen workarounds, for at least half a dozen bugs in the compiler.

johncolanduoni 9y ago
If you’re writing a kernel, you’ll almost certainly be using “-nostdlib” (or your compiler’s equivalent) so unique_ptr, etc. won’t be there. You could however write your own unique_ptr that allocates via whatever allocator you write for your kernel. See [1] for a decent overview of what using C++ in a kernel entails. [1]: http://wiki.osdev.org/C%2B%2B http://wiki.osdev.org/C%2B%2B
- throwaway613834 9y ago
  > If you’re writing a kernel, you’ll almost certainly be using “-nostdlib” (or your compiler’s equivalent) so unique_ptr, etc. won’t be there. Huh? unique_ptr has a customizable Deleter though; you should be able to provide a custom one so it doesn't call delete. And doesn't a kernel implement a kmalloc() or something anyway? You would just write your own operator new and have it do what your kernel needs, and the rest of the standard library would just work with it.
  - johncolanduoni 9y ago
    True, but the "rest of the standard library" is somewhat harder to port and last time I played with it (admittedly some years ago) no compilers were good at letting you pick and choose.
jcelerier 9y ago
> All the code that you need in order to support smart pointers, templates, move/copy semantics, exceptions and so on. smart pointers are their own classes, and exceptions would certainly be disabled in kernel-mode, sure, but for the rest ? which additional code ? there's no magic behind templates and move semantics, and no run-time impact. It's purely a compile-time feature.
CyberDildonics 9y ago
> and hope that the hardware learns about unique_ptr by osmosis Unique_ptr is just a template and does not need the standard library. Also move/ownership semantics don't need unique_ptr. > The last C++ codebase I was working on had at least a dozen workarounds, for at least half a dozen bugs in the compiler. There are at least four compilers that been extensively production tested - ICC, GCC, MSVC and Clang. Which one had these bugs and was it kept up to date?

by alxlaz 9y ago

johncolanduoni 9y ago

If you’re writing a kernel, you’ll almost certainly be using “-nostdlib” (or your compiler’s equivalent) so unique_ptr, etc. won’t be there. You could however write your own unique_ptr that allocates via whatever allocator you write for your kernel. See [1] for a decent overview of what using C++ in a kernel entails. [1]: http://wiki.osdev.org/C%2B%2B http://wiki.osdev.org/C%2B%2B

throwaway613834 9y ago
> If you’re writing a kernel, you’ll almost certainly be using “-nostdlib” (or your compiler’s equivalent) so unique_ptr, etc. won’t be there. Huh? unique_ptr has a customizable Deleter though; you should be able to provide a custom one so it doesn't call delete. And doesn't a kernel implement a kmalloc() or something anyway? You would just write your own operator new and have it do what your kernel needs, and the rest of the standard library would just work with it.
- johncolanduoni 9y ago
  True, but the "rest of the standard library" is somewhat harder to port and last time I played with it (admittedly some years ago) no compilers were good at letting you pick and choose.

jcelerier 9y ago

> All the code that you need in order to support smart pointers, templates, move/copy semantics, exceptions and so on. smart pointers are their own classes, and exceptions would certainly be disabled in kernel-mode, sure, but for the rest ? which additional code ? there's no magic behind templates and move semantics, and no run-time impact. It's purely a compile-time feature.

CyberDildonics 9y ago

> and hope that the hardware learns about unique_ptr by osmosis Unique_ptr is just a template and does not need the standard library. Also move/ownership semantics don't need unique_ptr. > The last C++ codebase I was working on had at least a dozen workarounds, for at least half a dozen bugs in the compiler. There are at least four compilers that been extensively production tested - ICC, GCC, MSVC and Clang. Which one had these bugs and was it kept up to date?