On Mon, Jul 29, 2013 at 1:57 PM, David Jeske <[email protected]> wrote:
> Not sure what you mean by class size fragility. >>> >> > AFAIK, C++ in-memory layouts and sizes are defined by inlining header > meaning, not by deferring to the DLL. This means that C++ new, and > stack-allocated classes inline the size of classes separately into the > caller and the DLL. This is a similar but more pervasive problem than the > FBC. By way of example, I believe the following to be true: > You are correct, but the problem isn't particular to C++. The problem arises in *any* language that directly supports unboxed types. Your example can be generated using a stack-allocated struct in C, for example. This is an inherent price of C-style efficiency. Without knowing object sizes, you can't resolve field offsets at compile time, and without that you can't generate anything remotely like efficient code at static compile time. > I suppose this is a lesser problem than the FBC, since it can be worked > around by forbidding direct or stack allocation, and always allocating > through factories. > Yes and no. Yes you can avoid the idiom you identify, but no, doing so doesn't solve the bigger issue, which is the need to know offsets within structures. I've occasionally thought that it would be really nice to have a tool that could compare two versions of a library and tell me whether the APIs are incompatible in a way that requires a version bump. There are so *many* useful tools we might have if the front end of a practical compiler were available as a library and did *not* make premature optimizations (e.g. don't constant-fold early like GCC does). [Objective-C] supports interface programming through dynamic-dispatch > rather than C++ MI ... > MI is a horror, and I think it's generally viewed outside the C++ world as something we have now learned from and will avoid in the future. Dynamic dispatch comes at a high performance cost unless you do runtime optimizations. > I know it isn't directly relevant to bitc because it's not anywhere close > to typesafe (and it doesn't have any form of generics/parametrics). > However, I think it's interesting to observe that Objective-C *is* > successfully used for modular (DLL) systems programming on MacOS/iOS in a > way that C++ has never succeeded. > Actually, in my view that *does* make it relevant, because it's something to learn from. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
