The Artima Developer Community
Sponsored Link

Weblogs Forum
Object Oriented Template Library ( OOTL ) version 0.1

14 replies on 1 page. Most recent reply: Dec 3, 2004 3:01 PM by Todd Blanchard

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 14 replies on 1 page
Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Object Oriented Template Library ( OOTL ) version 0.1 (View in Weblogs)
Posted: Nov 25, 2004 2:53 PM
Reply to this message Reply
Summary
I have made a first public release of the C++ Object Oriented Template Library ( OOTL ). An open-source library with the rather ambitious goals of providing object-oriented alternatives to the C++ primitives and the STL collections.
Advertisement
The C++ Object Oriented Template Library ( OOTL ) is a brand new open-source library, using the Boost C++ Library license with the rather ambitious goals of providing a more object-oriented alternative to the C++ primitives and the STL.

One of my biggest beefs with the STL and the C++ primitives, and a complaint I frequently hear being voiced, is that they are not object-oriented. One of the joys of C++ is that it is immensely flexible and powerful, so it does give us the tools to define our own object-oriented libraries.

Up until recently the only real obstacle I faced in making my own object oriented library was that polymorphism was expensive. The problem is now no longer significant with a new C++ interfaces library about to be released as a beta-release by Jonathan Turkanis called the Boost Interfaces Library ( BIL ). The BIL is not yet in fact a Boost library, but the name reflects the intention for eventual submission to the library.

The BIL is a set of macros which use a technique I wrote about in the September 2004 issue of the C++ Users Journal for implementing efficient interfaces without abstract base classes. The major advantages of this technique are that it provides us with run-time polymorphism without the overhead of virtual tables within objects. This means we can uses lightweight objects efficiently. Another advantage is that there is no need to pre-declare the intention of implementing interface as is required in Java and C#.

The OOTL has two primary sub-libraries, one for primitives and the other for collections. The OOTL primitives library, provides lightweight object-oriented alternatives to the C++ built-in types. The OOTL collections library provides a set of interfaces and classes for abstract data types such as Stacks, Queues, Deques, Arrays, Lists and so on.

The OOTL has some extensive documentation at http://www.ootl.org, it is downloadable through SourceForge at http://www.sf.net/projects/ootl and there is a google mailing list / discussion forum at http://groups-beta.google.com/group/ootl/


Steve Love

Posts: 20
Nickname: essennell
Registered: Sep, 2004

Re: Object Oriented Template Library ( OOTL ) version 0.1 Posted: Nov 26, 2004 1:52 AM
Reply to this message Reply
> One of my biggest beefs with the STL and the C++
> primitives, and a complaint I frequently hear being
> voiced, is that they are not object-oriented.


Quite deliberately in fact. It's generic. See below.

> One of the
> joys of C++ is that it is immensely flexible and powerful,
> so it does give us the tools to define our own
> object-oriented libraries.
> <p/>


Indeed. That's why C++ is referred to as multi-paradigm - you're not locked into one way of progamming.

However, why the desperate need for object orientation for container classes? Or algorithms/tools? Sure, I suppose a list IS-A collection, and an array IS-A collection, but do those relationships really need formalising?

What do you gain by abstracting away the concrete type of a collection? I'm afraid this smells of shoehorning one languages idioms on another.

We've had the discussion of primitive types being in a library before. I've still yet to see a convincing motivation for it.

Terje Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: Object Oriented Template Library ( OOTL ) version 0.1 Posted: Nov 26, 2004 4:46 AM
Reply to this message Reply
>> One of my biggest beefs with the STL and the C++
>> primitives, and a complaint I frequently hear being
>> voiced, is that they are not object-oriented.

>Quite deliberately in fact. It's generic. See below.

Yup.

In fact, as also Michael Feathers writes in "Working Effectively with Legacy Code" (an excellent book, by the way), any C/C++ program may be considered OO - without user-defined objects, you have just a single "global object" which is the global namespace. After all, member functions are typically implemented as regular functions, that are passed a pointer to the object as the first parameter.

>> One of the
>> joys of C++ is that it is immensely flexible and >powerful,
>> so it does give us the tools to define our own
>> object-oriented libraries.
>> <p/>

>Indeed. That's why C++ is referred to as multi-paradigm - >you're not locked into one way of progamming.

Again, true.

>However, why the desperate need for object orientation for >container classes? Or algorithms/tools? Sure, I suppose a >list IS-A collection, and an array IS-A collection, but do >those relationships really need formalising?

In fact, they _are_ formalised, as you know: as generic concepts (such as the "Container" concept). These are the abstract requirements of the types to be used with the components (both containers, algorithms and function objects). One great thing about this is that you can use built-in and user-defined types with STL.

Moreover, this means you can use types that have not been made to be used with STL, as long as they satisfy the concept requirements. This means there's no dependency of a common base class or interface, something you have with an OO approach.

In fact, before STL, there were several OO container- and algorithm libraries, but when STL came, it demonstrated that this could be done without inheritance from a common base or interface, and thus be usable with built-in types, as well.

I think instead the way forward is to have better support for generic concepts in C++.

Regards,

Terje

Steve Love

Posts: 20
Nickname: essennell
Registered: Sep, 2004

Re: Object Oriented Template Library ( OOTL ) version 0.1 Posted: Nov 26, 2004 5:02 AM
Reply to this message Reply
> > Sure, I
> > suppose a list IS-A collection, and an array IS-A
> > collection, but do >those relationships really need
> > formalising?
>
> In fact, they _are_ formalised, as you know: as generic
> concepts (such as the "Container" concept).


Yes, but what I meant was formalising in code, using IS-A relationships - public inheritance.

> One great thing about this is that you can use
> built-in and user-defined types with STL.
>
> Moreover, this means you can use types that have not been
> made to be used with STL, as long as they satisfy the
> concept requirements. This means there's no dependency of
> a common base class or interface, something you have with
> an OO approach.
>


Quite so. I think this is the general approach taken by the Boost Interface Lib referenced in the OP - but for different reasons. And syntax. You don't derive from the interface, just implement its characteristics. Anyone recognise compile-time polymorphism? :-)

> I think instead the way forward is to have better support
> for generic concepts in C++.

I agree with this in the general sense, particularly for iterators and algorithms, because it's not always clear-as-day which iterators are needed for which tools, especially if you've extended the library with your own containers and algorithms. Being able to concretely specify iterator types would be most useful.

STL concepts are contracts - I am a sequence, therefore I provide this interface, create these iterators, behave in this manner and have these performance characteristics - but enforcing this in the language would break much of the genericity allowed by having the Concepts as Conventions.

Boost's Concept Checking Library goes quite some way to allowing both; kind of Concept Safety in the sense of Type Safety.

Steve

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Object Oriented Template Library ( OOTL ) version 0.1 Posted: Nov 26, 2004 6:31 AM
Reply to this message Reply
> However, why the desperate need for object orientation for
> container classes? Or algorithms/tools? Sure, I suppose a
> list IS-A collection, and an array IS-A collection, but do
> those relationships really need formalising?

There are many benefits to be offered by an OO approach. Including cleaner syntax, better type-checking (when compared to using compile-time polymorphism),

> What do you gain by abstracting away the concrete type of
> a collection? I'm afraid this smells of shoehorning one
> languages idioms on another.

The code:

DoSomethingWithStack(ootl::IStack<Object> stack) 
{ ... }
is more generic than:

DoSomethingWithStack(std::stack<Object> stack)
{ ... }
and it is safer and simpler than

 template<typename Stack_T>
DoSomethingWithStack(Stack_T stack) 
{ ... }
> We've had the discussion of primitive types being in a
> library before. I've still yet to see a convincing
> motivation for it.

First off, there is no motivation against it as far as I can see. The OOTL is the first library in C++, that I know of, which provides run-time polymorphism without vtables in the object. This means there is virtually no reason not to use OO primitives.

Advantages of the OOTL primitives are:
- they provide RTTI (without rtti compiler switches on)
- they can be inherited from
- they can be delegated to ( not yet explained in the documentation, but is a feature of the BIL )
- they can be referred to using interfaces that can be defined later
- they can be used in heterogenous lists
- they make debugging easier

In general though, if you don't see value to object-oriented techniques, unfortunately I doubt that I will be able to have any influence in that regards.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Object Oriented Template Library ( OOTL ) version 0.1 Posted: Nov 26, 2004 6:41 AM
Reply to this message Reply
> In fact, as also Michael Feathers writes in "Working
> Effectively with Legacy Code" (an excellent book, by the
> way), any C/C++ program may be considered OO - without
> user-defined objects, you have just a single "global
> object" which is the global namespace. After all, member
> functions are typically implemented as regular functions,
> that are passed a pointer to the object as the first
> parameter.

Maybe this is true, technically, but it is not particularly useful in an object oriented design.

> >However, why the desperate need for object orientation
> for >container classes? Or algorithms/tools? Sure, I
> suppose a >list IS-A collection, and an array IS-A
> collection, but do >those relationships really need
> formalising?
>
> In fact, they _are_ formalised, as you know: as generic
> concepts (such as the "Container" concept).

Can that really be considered formalised? There is absolutely nothing to enforce or verify concepts. Using the OOTL you can express concepts properly using interfaces.

> These are the
> abstract requirements of the types to be used with the
> components (both containers, algorithms and function
> objects). One great thing about this is that you can use
> built-in and user-defined types with STL.

The same is true with the OOTL.

> Moreover, this means you can use types that have not been
> made to be used with STL, as long as they satisfy the
> concept requirements.

The implication seems to be that there is some kind of arbitrary restrictions on the OOTL that do no exist.

> This means there's no dependency of
> a common base class or interface, something you have with
> an OO approach.

Not neccessarily. The OOTL uses BIL interfaces types which are compatible with any object providing matching signatures, much like an STL concept. There is no need for any preparation in an object.

> In fact, before STL, there were several OO container- and
> algorithm libraries, but when STL came, it demonstrated
> that this could be done without inheritance from a common
> base or interface, and thus be usable with built-in types,
> as well.
>
> I think instead the way forward is to have better support
> for generic concepts in C++.

So you are clearly implying that I am going backwards. It is hard to not be annoyed by such statements. I would recommend taking a look at the documentation before you jump to conclusions.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Object Oriented Template Library ( OOTL ) version 0.1 Posted: Nov 26, 2004 6:46 AM
Reply to this message Reply
> Quite so. I think this is the general approach taken by
> the Boost Interface Lib referenced in the OP - but for
> different reasons. And syntax. You don't derive from the
> interface, just implement its characteristics. Anyone
> recognise compile-time polymorphism? :-)

Compile-time polymorphism has no way of formally verifying the concept/interface requirements on the type, which makes large-scale development complex.

Compile-time polymorphism is also useless in scenarios where the type is not know until run-time.

Keith Ray

Posts: 658
Nickname: keithray
Registered: May, 2003

Re: Object Oriented Template Library ( OOTL ) version 0.1 Posted: Nov 26, 2004 7:26 AM
Reply to this message Reply
I don't like that STL is so very dependent on "compile-time polymorphism". If I've written some code that takes a forward-iterator parameter, I'd like to be able to pass in ANY of the STL iterators into that function without recompiling it or making that function into a template function. Ditto for various STL containers that have common APIs.

The best C++ container library I ever used was the "Booch Components" library. It used templates, but it also used inheritance so you could have some degree of run-time polymorphism as well as compile-time polymorphism. Unfortunately, ownership of the Booch Components got transferred to Rogue Wave, who already had a larger (but not necessarily better) container library. I don't think they even sell the Booch Components any more.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Object Oriented Template Library ( OOTL ) version 0.1 Posted: Nov 26, 2004 7:57 AM
Reply to this message Reply
> I don't li1ke that STL is so very dependent on
> "compile-time polymorphism". If I've written some code
> that takes a forward-iterator parameter, I'd like to be
> able to pass in ANY of the STL iterators into that
> function without recompiling it or making that function
> into a template function. Ditto for various STL containers
> that have common APIs.

This is exactly one of the problems that I wanted to address with the OOTL.

The OOTL provides a single iterator class ( Iter<typename> ), which is used by the sequences ( ootl::Array and ootl::List ) and can be passed to functions:

template<typename Elem_T>
class Iter {
  Bool IsAtEnd();
  void GotoFirst();
  void GotoNext();
  Elem_T& Get(); 
}
This iterator is available through any class implementing ISequence through the function GetIter().

( actually the List class in version 0.1 doesn't support ISequence, but version 0.2 does. )

I plan on releasing in a future version of OOTL, a Object class which behaves much like boost::any and which will allow us to have Dynamically typed iterators, i.e. Iter<Object>.

Terje Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: Object Oriented Template Library ( OOTL ) version 0.1 Posted: Nov 26, 2004 9:48 AM
Reply to this message Reply
> > >However, why the desperate need for object orientation
> > for >container classes? Or algorithms/tools? Sure, I
> > suppose a >list IS-A collection, and an array IS-A
> > collection, but do >those relationships really need
> > formalising?
> >
> > In fact, they _are_ formalised, as you know: as generic
> > concepts (such as the "Container" concept).
>
> Can that really be considered formalised? There is
> absolutely nothing to enforce or verify concepts.

It depends on what you mean by "formalised". What I meant with it is that there are defined requirements for them. However, as you say, there's no direct support for concepts in C++ (although there are papers/proposals for this).

There are, however, ways to get some of the benefits of concept support, such as Boost Concept Check Library, or the CTL library I mentioned in another posting. Used together with boost::enable_if, you can actually overload on concepts, as well.

It seems the BIL library may do something similar, as you say, so I'll look into it.

> Using
> the OOTL you can express concepts properly using
> interfaces.

I'll look more into the documentation.

> > Moreover, this means you can use types that have not
> been
> > made to be used with STL, as long as they satisfy the
> > concept requirements.
>
> The implication seems to be that there is some kind of
> arbitrary restrictions on the OOTL that do no exist.

No, like I said in the posting, I had only looked a little at the docs, so my comparison above was mostly based on how traditional OO-versions of container- and algorithm-libraries work (such as in Java), where components need to inherit from interfaces and/or a universal base class. Judging from other postings in this thread, it seems I wasn't alone in making this connection.

However, as I understand, your library is different in this respect, which motivates me to take a better look at it. I guess my posting was kind of an "is this just another OO-framework, or different (i.e. something worth looking into more)?" question. :)

> > This means there's no dependency of
> > a common base class or interface, something you have
> with
> > an OO approach.
>
> Not neccessarily. The OOTL uses BIL interfaces types which
> are compatible with any object providing matching
> signatures, much like an STL concept. There is no need for
> any preparation in an object.

Interesting.

> > In fact, before STL, there were several OO container-
> and
> > algorithm libraries, but when STL came, it demonstrated
> > that this could be done without inheritance from a
> common
> > base or interface, and thus be usable with built-in
> types,
> > as well.
> >
> > I think instead the way forward is to have better
> support
> > for generic concepts in C++.
>
> So you are clearly implying that I am going backwards.

No, there was a "precondition" that apparently wasn't that clear, and I'm sorry for that. The "precondition" was: _if_ your library worked the same way traditional OO-libraries work. There's a reason STL was adopted, and the other pre-STL ones faded away. However, I understand your library is different.

> It is hard to not be annoyed by such statements.

Please don't take this as personal offence; none was meant. Like I said, my posting was not at least an attempt to see if this was worth looking more into. Your own blog and docs, with its emphasis on "OO" and "problems with non-OO things", was also I guess something I felt could need challenging, or at least a clarifying of what you were criticising about STL, or everything non-OO in general.

> I would recommend taking a look at the documentation before you
> jump to conclusions.

I will. As you see from the above, I had not come to any conclusion at the point of posting, simply because I knew too little about it. Jumping to conclusions is something I try to avoid. However, you might have taken my "provocative" posting (which was partly motivated by your own mentioned criticism of STL, etc.) as I having made up my mind. It was not so.

Regards,

Terje

Terje Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: Object Oriented Template Library ( OOTL ) version 0.1 Posted: Nov 26, 2004 9:58 AM
Reply to this message Reply
> > > In fact, before STL, there were several OO container-
> > and
> > > algorithm libraries, but when STL came, it
> demonstrated
> > > that this could be done without inheritance from a
> > common
> > > base or interface, and thus be usable with built-in
> > types,
> > > as well.
> > >
> > > I think instead the way forward is to have better
> > support
> > > for generic concepts in C++.
> >
> > So you are clearly implying that I am going backwards.
>
> No, there was a "precondition" that apparently wasn't that
> clear, and I'm sorry for that.

It was actually a little subtler than this, as well: In the paragraph above, I discuss the pre-STL OO libraries, and the following comment "I think the way forward..." was made with regard to them. IOW, if your library doesn't work the same way, then the comment wasn't meant for it. It was meant for those libraries, and libraries like them (being intrusive on the objects to be used with a particular library).

Regards,

Terje

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Object Oriented Template Library ( OOTL ) version 0.1 Posted: Nov 26, 2004 12:07 PM
Reply to this message Reply
Hello Terje,

Thanks for clarifying, and my apologies to having jumped to my own conclusions. Your posts are very appreciated.

> "Your own blog and docs, with its emphasis on "OO" and "problems with non-OO things", was also I guess something I felt could need challenging, or at least a clarifying of what you were criticising about STL, or everything non-OO in general."

I did not mean to imply that OO is the one true path, but rather to present techniques that allow OO and to present libraries which support OO techniques. I am methodology agnostic, despite what my writing may indicate. I see advantages and disadvantages in all of the paradigms, and I try to use whatever methodology is most appropriate to accomplish a given task. Yes, that even means I sometimes like to use good old fashioned structured programming ( gasp ).

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

You should just switch to Smalltalk Posted: Dec 1, 2004 9:26 AM
Reply to this message Reply
which has "everything is an object" just like you are trying to do - only the Smalltalk version is actually efficient and elegant.

I have taken my run at the numerics problem in the past and found that its not possible to handle type demotion in any kind of clean way. IOW, if you do something like

Int i = 2;
Int j = 4;

i/j needs to yield a float (fraction would be better), yet j/i can be safely demoted to an integer. After a little work with it you begin to conclude that everything will eventually get promoted to a double.

The less direct route (which you seem to have taken) is to have a common "Number" interface that everything is wrapped in and then do the type promotions and demotions in terms of hidden implementation classes. This ultimately turns out to be much less satisfactory in that you write a LOT more code and have thrown away any notion of type beyond number. It also forces you to go to heap allocation of many tiny objects.

Furthermore, I have to wonder why you didn't implement fractions directly as they are more exact than floats.

Anyhow, I think you're barking up the wrong tree here.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: You should just switch to Smalltalk Posted: Dec 1, 2004 10:45 AM
Reply to this message Reply
> which has "everything is an object" just like you are
> trying to do - only the Smalltalk version is actually
> efficient and elegant.

The OOTL is an attempt to allow more object-oriented style programming in C++. It is inspired to some small degree by Smalltalk. I have never seen any evidence Smalltalk is not more efficient than the OOTL, but I highly doubt it.

> I have taken my run at the numerics problem in the past
> and found that its not possible to handle type demotion in
> any kind of clean way.

One clean way is to disallow implicit demotion like Pascal. Or to allow a programmer to decide which they prefer, like Heron.

> After a little
> work with it you begin to conclude that everything will
> eventually get promoted to a double.

That is a bizarre conclusion. x = 2 + 4; shouldn't be promoted to a double.

> The less direct route (which you seem to have taken) is to
> have a common "Number" interface that everything is
> wrapped in and then do the type promotions and demotions
> in terms of hidden implementation classes. This
> ultimately turns out to be much less satisfactory in that
> you write a LOT more code and have thrown away any notion
> of type beyond number.

How much code is needed to write number classes is irrelevant. Writing numeric classes should occur several orders of magnitude less frequently than they are used.

> It also forces you to go to heap
> allocation of many tiny objects.

This is a false assumption on your part. Being an object doesn't imply they are neccecssarily allocated on the heap.

> Furthermore, I have to wonder why you didn't implement
> fractions directly as they are more exact than floats.

I will eventually add fractions to the OOTL ( and to Heron )

> Anyhow, I think you're barking up the wrong tree here.

That's fine, but I like barking up trees ;-)

You also might want to take a look at http://www.codeproject.com/cpp/ootl.asp

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Oh, I've looked Posted: Dec 3, 2004 3:01 PM
Reply to this message Reply
at your link.

Its a kind of a clever trick. But its just a trick.

Your entire project is basically an attempt to disable static typing and enable dynamic typing through code generation and "stupid macro/compiler tricks".

IOW, you're trying to pound screws with a hammer.

Using the <a href="http://www.squeak.org">right tool</a> will produce much prettier and more efficient results.

Flat View: This topic has 14 replies on 1 page
Topic: The Six Myths of Creativity Previous Topic   Next Topic Topic: Tools from the Garden Shack: Natural Programming Language

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use