4 ms·

Because I want full encapsulation without giving up by-value semantics. I want my clients to be able to take objects of some opaque record type that I've define

Because I want full encapsulation without giving up by-value semantics. I want my clients to be able to take objects of some opaque record type that I've defined, and put them entirely on the stack, or in some contiguous block of memory entirely of their making, without ever getting to know the constituent fields of the record. I want it all, I want to have my cake and eat it too. When the parent (er, great grandparent?) says their parent is wrong to deny that headers only reveal the interface, I think it's a little disingenuous to base that on an unrevealed assumption that PImpl is in play. PImpl is basically the the idiom that begot Java. One reason I might opt for C++ over Java, is a desire for finer control over the location of memory -- but it's important for me to know that to actually get that, I'll probably have to sacrifice information hiding. It's a trade-off. Yes, on some level it's better to have the option to make that trade-off, but the product here is "encapsulation or value semantics", not "encapsulation and value semantics". Mind, I'm not a C++ developer. Maybe these days link-time heroic optimization makes the "right" decisions and collapses these kinds of indirections in all the sorts of situations you'd want it to. I write a lot more Java, and my understanding is that HotSpot gets up to a lot of heroics pertaining to this stuff these days -- I've noticed HotSpot will churn through a workload involving processing a collection of records far more quickly if you can arrange for it to stream through an array, even if you'd expect the records to be scattered randomly throughout memory.

ryl00 8y ago
> I want it all, I want to have my cake and eat it too. Conceptually this should be possible with some preprocessor/header tinkering; something like: private.h: struct Bar { double x; double y; }; #define BAR_DEFINED public.h: #ifndef BAR_DEFINED struct Bar { char opaque[16]; }; #endif struct Foo { Bar bar; }; consumer.cpp: #include "public.h" private_implementation.cpp: #include "private.h" #include "public.h"
- blt 8y ago
  this code can crash on platforms where unaligned access is not allowed. you need an alignas on public Bar. and of course the catastrophic bugs if the size of opaque is not kept in sync properly. the point is: the module system should be doing something like this for you behind the scenes.
nchie 8y ago
Well, there is a way to have them on the stack even with PImpl: http://www.gotw.ca/gotw/028.htm http://www.gotw.ca/gotw/028.htm However I'd say it's an ugly hack which should only ever be used if you _really_ need the performance.
jcelerier 8y ago
> I want my clients to be able to take objects of some opaque record type that I've defined, and put them entirely on the stack if you want to put the object on the stack, the compiler has to know the size of the object to reserve enough space on the stack. How can it know the size of the object if it does not have its full definition somewhere ?
- pjmlp 8y ago
  Module symbol table for example, where only the compiler can actually see the complete information about a type, although the consumer code can only access what is exposed as public.
  - gpderetta 8y ago
    This is fine if you can recompile a program against a new version of the library, but if you just want to relink it doesn't work well. This is actually while common when a .so is replaced with a newer version in a system without rebulding the world. Some languages have, like ADA I think, have first class support for runtime sized, stack allocated types, so it might work there.

ryl00 8y ago

> I want it all, I want to have my cake and eat it too. Conceptually this should be possible with some preprocessor/header tinkering; something like: private.h: struct Bar { double x; double y; }; #define BAR_DEFINED public.h: #ifndef BAR_DEFINED struct Bar { char opaque[16]; }; #endif struct Foo { Bar bar; }; consumer.cpp: #include "public.h" private_implementation.cpp: #include "private.h" #include "public.h"

blt 8y ago
this code can crash on platforms where unaligned access is not allowed. you need an alignas on public Bar. and of course the catastrophic bugs if the size of opaque is not kept in sync properly. the point is: the module system should be doing something like this for you behind the scenes.

nchie 8y ago

Well, there is a way to have them on the stack even with PImpl: http://www.gotw.ca/gotw/028.htm http://www.gotw.ca/gotw/028.htm However I'd say it's an ugly hack which should only ever be used if you _really_ need the performance.

jcelerier 8y ago

> I want my clients to be able to take objects of some opaque record type that I've defined, and put them entirely on the stack if you want to put the object on the stack, the compiler has to know the size of the object to reserve enough space on the stack. How can it know the size of the object if it does not have its full definition somewhere ?

pjmlp 8y ago
Module symbol table for example, where only the compiler can actually see the complete information about a type, although the consumer code can only access what is exposed as public.
- gpderetta 8y ago
  This is fine if you can recompile a program against a new version of the library, but if you just want to relink it doesn't work well. This is actually while common when a .so is replaced with a newer version in a system without rebulding the world. Some languages have, like ADA I think, have first class support for runtime sized, stack allocated types, so it might work there.