Boost logo

Boost :

From: Jack M. Thompson (JMThompson_at_[hidden])
Date: 2002-01-25 00:15:56

>I am not sure what you mean by re-entrance in the context of your
Every product created can have another DataStore object inside of it,
which can again, hold any type of objects in its hierarchy.

Maybe re-entrance is the wrong way to describe it. One way to describe
the system is...

The Monarch is the top node. Every item needs a parent, and when there
is no parent, it needs to be in the orphanage maintained by the Monarch.
Every DataStore is the child of a Primitive. This Primitive may be the
orphanage. Every ProductList is the child of a DataStore. Every
Primitive is the child of a ProductList. Every DataStore is the child
of a Primitive....

-----Original Message-----
From: dp11229 [mailto:dpodbori_at_[hidden]]
Sent: Thursday, January 24, 2002 12:11 PM
To: boost_at_[hidden]
Subject: [boost] Re: A tip from the Dr.

Hi Jack,

I read your post with interest, though I am not sure what you mean by
re-entrance in the context of your system.

The issue of single base class--based hyerarchies have been
continuously discussed over the years in C++ community and some
seminal books on C++ deal with this subject in great detail (see, for
example, "Design And Evolution of C++" and "More Effective C++").

This is not the direction in which modern C++ design is evolving
(see "Modern C++ Design" by Alexandrescu)

However other languages utilize a concept similar to what you
discuss, e.g. Java, Python and (especially) Ruby. Unlike C++, these
languages are dynamically typed, have elaborate root classes and lack
the notion of templates.

Best regards,

--- In boost_at_y..., "jackthompson99" <JMThompson_at_E...> wrote:
> Hey guys,
> I sent an e-mail to Dr. Stroustrup a couple nights ago, and he
> replied, "Have a look at They exist specifically to
> provide better libraries in the context of the C++ standard library
> and to act as a test bed for new library ideas".
> So, here I am. I've installed and built my boost libraries, and
> trying to figure out how to dig in.
> Anyway, here's what I was telling the Dr.
> I've been using C for about a decade, and C++ for about 7
> yrs. I'm a huge fan of your invention, and I honestly feel like
> name should eventually be as well known as Tesla and Edison. And
> Standard Template Library is an incredibly well engineered system.
> have a way to use it that is generic enough that it may be a
> candidate to be another standard. I know that's a lot to say. I'd
> like to explain it briefly, but first I should explain why I find
> useful.
> Since I started working with assembler, I've always felt like
> the language I was using was missing something. I've used an
> assortment of languages, and it seems like they are all missing the
> same thing. The main part isn't really missing from C++, it's just
> not commonly understood. The concept of virtual construction is
> core of the issue. Now I know that this problem is solved, but it
> really could stand for just one more thing to wrap it up into
> something usable for any ordinary C++ developer….
> Using a virtual constructor by way of a template, a developer
> can easily create any kind of object based on any type of
> but what good is that when the developer has exhausted all of his
> efforts on just building a simple system to dynamically create
> objects. The developer needs a way to organize these objects,
> without building another data warehouse. And I have never heard of
> complicated database that shouldn't be fully hierarchical. So, the
> system should be one hundred percent re-entrant.
> Well, I have such a beast. I'm not done with it yet. I'm
> just now finishing up a project for Textron, where some of this
> concept was cultivated into my skill set. I am having a rough time
> explaining the system to my boss, and I'm in a real bind, but
> another story. The main thing that I've learned from this job is
> that the world needs to come together on one simple international
> standard for dealing with data and persistent C++ objects.
> I've used my ClassFactory / DataStore system as a foundation
> for another library that I call the WinFactory. This system simply
> uses the ClassFactory / DataStore as a database manager. The
> held in the database are simply graphical user interface
> This worked out really well, `till by boss took it apart. But I
> a version of it that I'm re-writing at home that is much better.
> database can be held either in a simple text format, resembling
> hypertext, or a binary file. The system relies heavily on the
> manager, so fast memory allocation is required.
> I have also populated an MFC user interface with data held in
> these objects. The system seems to be able to flex with just about
> anything, and I feel like it could at least contribute to
> about new standards that are based on your standards. By the way,
> need to find a team that I can work with who has good work ethics
> integrity. Suggestions would be much appreciated.
> .....
> So, I've looked at the library list in Boost, and haven't
> anything like what I've built. I'm going to explain the system
> I'm going to create for
> The main concept behind the system is a warehouse environment. The
> warehouse has isles of goods. Each isle is any length, and each
> contains exactly one type of product. And every product contains a
> single pointer which is initally NULL. This makes it so that when
> you pull the product off the shelf and open it, you will see
> the product is ( characters, integers, strings, etc. ), and you
> find one more thing. It's called the nest. Now, until you try to
> use the nest, it's empty (NULL). But when you need it, it is
> created. What is this nest you ask? It's another warehouse. Just
> like the one that it is contained within.
> So, the entier concept is one hundred percent re-entrant. This
> it easy to build hierarchical infrastructures. The objects can be
> virtually any C++ thing. They persist with the greatest of ease to
> simple IO objects.
> User interfaces are easy to build with this system. Content
> view it as a script. C++ programmers view the script as C++
> Again, I need to finish re-writing the system, and I need to
> it. But I feel like it is a candidate to become another Boost
> library.
> The main thing that is accomplished here is that I have just one
> database system that can used for every aspect of a typical
> application. Since the product of the factory is a simple C++
> object, it can, of course, hold virtually any other C++ object.
> the object could be an animated button on the screen, or a phone
> number, or any other object you want.
> Here's the catch. All products are based on the Primitive base
> class. All Primitives are based on a root class that maintains the
> objects identification. The identification could be anything, but
> they should all be the same (mutable). And, the Primitive base
> class needs to be constructed with a reference to the Products
> (the product list).
> The primitive base defines a few virtual functions, including
> The = operator lets the coder turn an entire DataStore object off
> on. All Products involved will be switched.
> Of course, you can turn on or off any node in the hierarchy
> The Fields() function is used to cause every data member to persist
> in storage.
> Each member gets the following function call in Fields()
> Field("ConcreteType",ConcreteType); // ConcreteType can
> be any type defined in the factory's parser and IO objects.
> Here is a sample:
> // Home.h
> class Object: public Primitive
> {
> public:
> Object(ProductList& pl) : Primitive(pl) {}
> virtual bool Fields();
> private:
> int MyInt;
> string MyString;
> vector<string> MyStringVector;
> // many more types are defined, and any developer can add on
> };
> Robot(Object,"Object") // I don't like macros, but this one
is worth
> it. It expands to about three lines.
> bool Object::Fields()
> {
> //The Primitive base defines Fields as pure virtual, so first
> derivatives can't call it. Anything based on this class should
> this classes Fields().
> // These will serialize in the proper direction based on the
> return of IsLoading()
> Field("MyInt",MyInt);
> Field("MyString",MyString);
> Field("MyStringVector",MyStringVector);
> return true; // false on error
> }
> Now, the data can be saved in text format or binary. Binary is
> simple. Each item is written to and read from the disk with it's
> identifier.
> The text format is simple too, approximately the same thing
> but it's formatted in a sort of hypertext style… Here is what
> above data could look like:
> <Object:MyObjectName;
> MyInt:29349;
> MyString:Some string
> with new lines.; // still ends with a semi\n. – semis in
> string are parsed into #xxx;
> MyStringVector:fisrt string;
> MyStringVector:second string;
> > // end MyObjectName
> Ok, so some typical weaknesses are evident. But dealing with the
> semi is no big deal, and the redundancy in the MyStringVector names
> could be changed. But look what it gives you….
> So far, no big deal. We can all write parsers. Here's the cool
> part. This object can have babies. Any type of babies. Could be
> the same type, could be different. Here's how it looks when it has
> children:
> <Object:MyObjectName;
> MyInt:29349;
> MyString:Some string
> with new lines.; // still ends with a semi\n. – semis in
> string are parsed into #xxx;
> MyStringVector:fisrt string;
> MyStringVector:second string;
> <AnotherTypeOfObject:FirstBorn;
> // Might not have any data.
> > // end FirstBorn
> > // end MyObjectName
> And, if the FirstBorn has children…
> <Object:MyObjectName;
> MyInt:29349;
> MyString:Some string
> with new lines.; // still ends with a semi\n. – semis in
> string are parsed into #xxx;
> MyStringVector:fisrt string;
> MyStringVector:second string;
> <AnotherTypeOfObject:FirstBorn;
> // Might not have any data.
> <Object:YesAnotherObject;
> MyInt:922039;
> // leave the other fields with default values
> >
> > // end FirstBorn
> > // end MyObjectName
> Ok, so let's say we have this file on the disk, and we'll call it
> FamilyTree.txt. Here's the code to load it:
> void funk()
> {
> PathString FileName("FamilyTree.txt")
> Input in(FileName,text);
> DataStore ds;
> ds<<in;
> if (Monarch.Error()) return; // error occurred somewhere
> }
> and here's how it can be saved;
> void funk()
> {
> PathString FileName("FamilyTree.txt")
> Output out(FileName,text);
> DataStore ds;
> ds>>out;
> if (Monarch.Error()) return; // error occurred somewhere
> }
> Now you data store has a map<Identification,ProductList*>, and some
> methods to index and search. One very common scenario is the
> knows what kind of object he is looking for in the data store. So,
> to get the stores list of type Object, do this:
> ProductList& pl=ds["Object"]; error will return an empty
> product list
> The Product list is a simple vector of Primitive*. If you know
> you are looking for MyObjectName in the list of Objects, just do
> Object& o=(Object&)pl["MyObjectName"];
> It is important to check for errors here like this:
> if (o.Error()) {/*error handler */}
> if it passes that check, then the Object is safe. Otherwise o is
> actually the ErrorProduct that is safely held in the DataStore's
> Monarch.
> The DataStore and Product list are just simple map<> and vector<>
> implementations. The Factory system is no magic either. It just
> a list of robots, and those robots are virtual constructors. The
> the nest is created is by the use of a pure virtual base class that
> is defined before the Primitive. The DataStore is derived from
> base. This makes it so that the Primitive can call the DataStore
> it's pure virtuals. There are only a handful of things that ever
> need to happen in this scope. They are mainly construction,
> destruction and on/off using the assignment operator with a boolean
> parmameter.
> About the list boxes and treeview controls I mentioned. I have
> two versions so far, one for the MS Windows common controls, and
> for the MFC TreeView and ListView controls. They do much the same
> thing. Basically, you don't ever need to think about those
> intricacies again. This think of it as a DataStore. The tree view
> is loaded as if it is just another object, and populated with
> DataStore, or the same one. It's incredibly simple to use. And it
> means that all of the applications' data can be organized in one
> simple system.
> The average GUI is nothing more than a hierarchy of windows. Some
> are tree controls, some are buttons, some are sliders, some are
> windows, some are images, etc. The concept is the same:
> <Window:Main;
> <Window:SubWindow;
> <TreeView:TreeInSub;
> DataStorage:; //
> could be anywhere. Input object needs support for every protocol
> >
> > // SubWindow
> > // Main
> The possibilities are endless, `cause the ClassFactory / DataStore
> system has doesn't care what type the objects are. That's what the
> Robots are for.
> So, I don't know if this is the best way to do it, but we do need
> something simple that uses ONLY C++. The parser could probably be
> faster and smaller, but the concept is rock solid.
> What do you think?????

Info: Send unsubscribe requests to:

Your use of Yahoo! Groups is subject to

Boost list run by bdawes at, gregod at, cpdaniel at, john at