Software Development

Scorpions4ever gave this piece of code.

class outer {
private:
    int x;
    class inner {
    private:
        outer *out;
        inner(outer *o) { out = o; }
        int do_something(void) {
            out->x = 10;
            return out->x;
        }
    };
};

This happens to be very close to what I have as it relates to the pointer I want to eliminate. The 'outer *out;' line is what I want to eliminate though. So how would I do that?

Before anyone else answered, I had found the answer. And it's not pretty.

class outer {
private:
    int x;
    class inner {
    private:
        int do_something(void) {
          outer *ptr = (outer*)((char *)this - (size_t) &(((outer*)0)->in));
          // call some func with ptr.
        }
    } in;
};

The version here is slightly modified from the one in the C thread linked above (uses char* instead of size_t for casting 'this').

Anyhow, I no longer need to store a pointer. I can simply compute the address of the outer class.

The user LittleGrin has three times claimed that my design is flawed.

#1

However, I repeat, that you have a fundamental design problem, and probably need to redesign your complete class structure from scratch.

#2

Originally posted by Vorlath:

I think you misunderstand the problem. My inner classes don't use any information from the outer class at all. I simply want a pointer to the outer class.

Well, no, by this comment you've convinced me that I understood the problem. Your design is broken, but you are assuming your design is correct, and seeking a hack to make things work anyway.

#3 (My personal favourite)

Originally posted by Vorlath:

It's a rather simple concept. I can't really screw it up since it's so simple. I just wanted to reduce useless memory usage. Just because I use a hack to do this doesn't mean my design is flawed.

The fact that you needed to use a hack is evidence your design is flawed. Your ability to delude yourself otherwise does not alter the evidence.

Is LittleGrin right? I tried to explain that the hack is not a necessity, but rather an optimization. Project V will work just fine without it. But if you've followed how the internals of Project V are built, you know it's built as a set of nodes with backlinks. So the outer class is that very node. The internal classes are for handling forward and back links. IOW, they are for handling sets.

Sets are different than what the node itself is meant to do, but those sets are still an integral part of what makes the entire system work. So I thought the best compromise was to have internal classes. I should mention that I usually never use internal classes, so I'm not sure exactly under what other circumstances you would use internal classes.

Here is that class.

class NEntry
{
public:
  // Forward named sets.
  class ForwardT
  {
  public:
    NEntry *source;
    ForwardMap Forward;
    __fastcall ForwardT(NEntry *ent);
    __fastcall ~ForwardT();
    ForwardPair* __fastcall Create(const UnicodeString &index, NEntry *Link, unsigned int flags);
    ForwardPair* __fastcall Create(const UnicodeString &index, NEntry *Link, const UnicodeString &reverseIndex, unsigned int flags);
    ForwardPair* __fastcall Find(const UnicodeString &index, const NEntry *Link) const;
    void __fastcall Clear();
  };

  // Reverse named sets.
  class ReverseT
  {
  public:
    NEntry *dest;
    ReverseMap Reverse;
    __fastcall ReverseT(NEntry *ent);
    __fastcall ~ReverseT();
    void __fastcall Clear();
    NEntryReverseLinkList* __fastcall Create(const UnicodeString &index);
    NEntryReverseLinkList* __fastcall Find(const UnicodeString &index) const;
    void __fastcall Delete(const UnicodeString &index);
  };

  ForwardT Forward;  // Forward sets (where we point to other NEntry's).
  ReverseT Reverse;  // Reverse sets (where other NEntry's point here).

  NID *FID;  // Unique ID (Interned)
  UnicodeString *FName; // Node name (Interned)

  void __fastcall SetName(const UnicodeString &name);
  UnicodeString& __fastcall GetName() const;
  void __fastcall SetID(const NID &ID);
  NID& __fastcall GetID() const;

  __property UnicodeString Name = {read = GetName, write = SetName};
  __property NID ID = {read = GetID, write = SetID};

#define NENTRY_FLAGS_VALUE 1
#define NENTRY_FLAGS_LOCK 2
#define NENTRY_FLAGS_DELETE 4
  unsigned int Flags;
  NEntryValue *Value;

  void __fastcall CreateID();
  __fastcall NEntry();
  virtual __fastcall ~NEntry();
  void __fastcall MassDelete();

  bool __fastcall GetIsValue() const;
  void __fastcall SetIsValue(bool v);
  bool __fastcall GetIsDeleted() const;
  void __fastcall SetIsDeleted(bool v);
  bool __fastcall GetIsLocked() const;
  void __fastcall SetIsLocked(bool v);

  __property bool IsValue = {read=GetIsValue, write=SetIsValue};
  __property bool IsDeleted = {read=GetIsDeleted, write=SetIsDeleted};
  __property bool IsLocked = {read=GetIsLocked, write=SetIsLocked};
};

There's more to it than that. ForwardPair, ForwardMap and ReverseMap are also internal classes or typedefs.

In any case, "NEntry *source;" and "NEntry *dest;" are the lines I want to get rid of. And I did using the hack mentioned above.

Other than ForwardMap and ReverseMap, what do I have that uses memory?

1. NID *FID (4 bytes)
2. UnicodeString *FName (4 bytes)
3. unsigned int Flags (4 bytes)
4. NEntryValue *Value (4 bytes)
5. NEntry *source (4 bytes)
6. NEntry *dest (4 bytes)

Total = 4*6 = 24 bytes.

If I remove #5 and #6, I get 16 bytes. That's a 33% improvement. Sure, there's an STL map for the forward set and reverse set. Not sure how much an empty set takes, but it can't be a whole lot. So 8 bytes less per node is important. It means that for every two nodes, I can allocate an extra one where I could not before. With the sets, maybe it'll take 3 to 6 nodes before I get an extra free node. But that's still significant.

Project V works just fine as far as creating networks, types, hierarchies, sets, instances and components. If my design is flawed, then everything I've written up until now is garbage, yet it works. I'm implementing events as I type (well, minutes ago) and it's going well. These events will allow the GUI to be automatically updated when something changes in any of these nodes. And how do I register events? Through an event node that is stored in another node's event set. That's possible with those pesky internal classes that keep track of all this stuff for you.

I also use internal classes because I don't want the node itself to be cluttered with set functionality. That's not really its job.

But just to build a component, it takes MANY of these nodes. It takes one for the META_TYPE to say it's a type. Then we have one for the type itself of COMPONENT. Then we have another one that is derived from COMPONENT that will define the inputs and outputs. The inputs and outputs are sets using those internal classes. Inside the input and output sets, you drop more nodes that specify the instances, each of which will derive from its own types. Then there are the implementations that derive the entire component definition along with connections, etc.

The user doesn't actually deal with this directly. That's what the GUI is for. Design time components will be able to deal with it directly for certain things like adding extra inputs and outputs, or adding new connections. But even then, you won't be dealing with RAW nodes.

The point is that there are a LOT of these nodes. The more of them I can store in RAM, the better. It's not a necessity. But it is beneficial.

I suppose this is some sort of code review, or a design review. I really like the way my system works. It's extremely flexible and I can build anything on top of it. That's what made the event system possible. See Steve's Universal Design Pattern for more information. Note that I include more functionality than what is found there and that I actually came up with all of this before I knew there was a name for it. When I had read Stevey's article, I wished I had that information a LONG time ago.

Here's my favourite line by Steve.

If you're writing this in C++, then may God have mercy on your soul.

Seems the deck is stacked against me. Other than SAYING my design is flawed, I don't see any specific reason why this would be so. Is using a hack that BAD that it would turn a good design into a bad one? Or is my design flawed from the beginning?

(BTW, I'm confident enough in what I'm doing to keep going forward regardless of what someone says on a C++ forum. But there is enough controversy that I thought this would make for an interesting topic. I'm also looking for suggestions if anyone has any.)