RE: [boost] Re: A tip from the Dr.

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

> This is not the direction in which modern C++ design is evolving

I know what you mean.  It seems like modern programmers seem to want the
language to become simpler.  So they use it in a simple way.  They pay
for that choice by doing much more work than they need to.

This type of system works great for all kinds of cool stuff.  Polygonal
character engines, and three dimensional environments are based on
hierarchies.  All kinds of graphical user interfaces, including video
games are best built out of hierarchies.

The underlying system should always be the same.  Templates need to be
used to specialize the implementations.  Optimizations can be made by
switching the vector bases with list bases, or visa versa depending on
requirements. The base classes Identifier, which is one of only two data
members in the base class, can be a template type so that the identifier
is whatever the implementation requires.  In a simple gui, the id might
be strings.  In a real time application, the id might be bytes (in cases
when there are usually only a few items per node, and don't ever exceed
255).

I think we need a standard foundation for this concept.

-----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,
Dmitry

--- 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 boost.org. 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 
I'm 
> 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 
your 
> name should eventually be as well known as Tesla and Edison.  And 
the 
> Standard Template Library is an incredibly well engineered system.  
I 
> 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 
it 
> 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 
the 
> 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 
identifier, 
> 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 
a 
> 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 
that's 
> 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 
objects 
> held in the database are simply graphical user interface 
components.  
> This worked out really well, `till by boss took it apart.  But I 
have 
> a version of it that I'm re-writing at home that is much better.  
The 
> database can be held either in a simple text format, resembling 
> hypertext, or a binary file.  The system relies heavily on the 
memory 
> 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 
discussions 
> about new standards that are based on your standards.  By the way, 
I 
> need to find a team that I can work with who has good work ethics 
and 
> integrity.  Suggestions would be much appreciated.
> 
> 
> .....
> 
> 
> So, I've looked at the library list in Boost, and haven't 
recognized 
> anything like what I've built.  I'm going to explain the system 
that 
> I'm going to create for Boost.org. 
> 
> The main concept behind the system is a warehouse environment.  The 
> warehouse has isles of goods.  Each isle is any length, and each 
isle 
> 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 
whatever 
> the product is ( characters, integers, strings, etc. ), and you 
will 
> 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 
makes 
> 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 
editors 
> view it as a script.  C++ programmers view the script as C++ 
objects.
> 
> Again, I need to finish re-writing the system, and I need to 
document 
> 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.  
So, 
> 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 
parent 
> (the product list).
> 
> The primitive base defines a few virtual functions, including 
> 	
> The = operator lets the coder turn an entire DataStore object off 
or 
> 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 
call 
> 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 
happens, 
> but it's formatted in a sort of hypertext style…  Here is what
the 
> 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 
coder 
> 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 
that 
> you are looking for MyObjectName in the list of Objects, just do 
this:
> 	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 
has 
> a list of robots, and those robots are virtual constructors.  The 
way 
> 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 
this 
> base.  This makes it so that the Primitive can call the DataStore 
by 
> 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 
built 
> two versions so far, one for the MS Windows common controls, and 
one 
> 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 
another 
> 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 
text 
> windows, some are images, etc.  The concept is the same:
> <Window:Main;
> 	<Window:SubWindow;
> 		<TreeView:TreeInSub;
> 		
> 	DataStorage:http://www.jackmthompson.com/menu.cfx;	// 
> 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: http://www.boost.org  Send unsubscribe requests to:
<mailto:boost-unsubscribe_at_[hidden]> 

Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/