On Tue, Sep 18, 2012 at 11:16 AM, Marvin Humphrey > These OFFSET variable lookups are merely a question of optimization. We > haven't even done significant benchmarking to measure how much they cost -- > the only data point we have is that when I marked all methods in InStream and > OutStream as `final` (so that those method symbols resolve as direct function > invocations rather than go through vtable dispatch) there wasn't a measurable > change on our indexing benchmark.
A good hope, but I think/hope there are going to be many more variable accesses than function calls. But I suppose one can always cache the offset locally in the very few few ultra-critical loops. >> I love the simplicity of a simple struct: no macros, no accessors, no >> opacity. > > I can't get on board with "no opacity" being a good thing. :\ I think I agree with you, and am using "opacity" in a difference sense here. Data hiding for non-API items is great. But I'm referring to the "what you see is what you get" aspect of C that makes me prefer it to C++. When one calls uses a struct in C, one knows that nothing untoward is going on behind the scenes. Making every access to something that feels like a struct do a couple lookups and extra memory accesses strikes me as untoward. For the base library, I _want_ portable assembly, and _want_ to be able to accurately guess what's happening behind the scenes. > Expecting programmers to reserve slots with dummy variables is a grotesque > workaround and a huge burden. We'll, very rarely would any users of the Lucy library need to do this. It would be only be for the parts of the core library that we feel compelled to make part of the published API but that for some reason can't be finalized. > It might be the only way to make C++ work, but > can't we learn from the past rather than repeat it? Well, I suppose BeOS is not a great example to be looking at as a model of success. :) >> If there is any way we can keep it [simple struct access] for instance >> variables, I think we should. > > The proposal on the table isn't any more complicated than a struct. The way > the fields are laid out in memory is identical. While the second sentence is true, I strongly disagree with the first. The cognitive load is extreme. In addition to wanting it to act like C, I think we benefit from making it look like C. I'm also afraid that we're going so far into a private dialect that we won't be accessible to C programmers who want to jump in. We've already got the barrier of the Clownfish hierarchy. While I suppose you can argue that anyone who makes it over that hurdle won't be turned off by this, we need to be accessible to host-language experts who haven't used a lot of C. > The only difference is that unlike Java and C#, C only provides native syntax > for accessing a member variable when its offset is known at compile-time. > Some parts of C are antiquated. This is one. I worry we'd just be recreating C++ badly here. What are you reasons for not just making the jump at this point? The part I'd prefer not to give up is the ability to reason about the efficiency of a routine by eyeing the source. > Furthermore, the quasi-accessor does the thing by default, while direct > access, which is meant to be simple, ironically requires that users possess a > sophisticated understanding of the "fragile base class" problem in order to > program safely. What I like about the "simple struct" approach, is that the demands are solely on the authors of the core Lucy library. No need to always use an inexplicable macro. The extension writers and language porters never have to worry about it: they use a struct, and it just works. I think the only time there would be any danger to users would be if we were to accidentally make a release that altered the layout of the core structs. I don't see this as being a large danger. While I appreciate the intent, and think I understand the "Fragile Base Problem" pretty well, I don't think it's pressing issue to allow member variables to be added ad libitum to the core classes. --nate
