The Artima Developer Community
Sponsored Link

Weblogs Forum
Bolt-Ins for Contract and Extension Classes

16 replies on 2 pages. Most recent reply: Apr 28, 2005 2:53 PM by Christopher Diggins

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 16 replies on 2 pages [ « | 1 2 ]
indranil banerjee

Posts: 38
Nickname: indranil
Registered: Nov, 2004

Re: Bolt-Ins for Contract and Extension Classes Posted: Apr 28, 2005 2:46 PM
Reply to this message Reply
> > BTW, are you aware of the approach Andrei Alexandescu
> has
> > taken to produce a well factored policy based string
> class
> > with flex_string?
> >
> I was not aware of this, would you mind summarizing what
> the relevant portions of his work are?

It's very cool. It has the same interface as std::basic_string. But there is an extra template parameter on the type which specifies different Storage policies. The Storage policies manage flex_string's actual data.

There are some policies provided with the library. One where the data is stored in a vector<CharType> , another where the data is in a CharType* array allocated by malloc/free. And another for small strings where the data is stored is an fixed size buffer on the stack. The last is my favourite for small strings. There are also storage policies for copy on write strings and others.

You can write your own storage classes if you need to and just drop them into the template. And you can use them just like familiar basic_string's

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Bolt-Ins for Contract and Extension Classes Posted: Apr 28, 2005 2:53 PM
Reply to this message Reply
> > > So I would strongly favour implementing those methods
> > as
> > > non member functions.
> >
> > Why?
> Because they (the String_ext methods) dont need to
> be members.
> They only operate on the public String interface, they
> dont need access to the protected parts of String_Impl.
> They dont override any of String_Impl's members, they are
> just extensions.
> They dont have any state of their own. So dont need to be
> in a class at all.

Of course they don't need to be. No member function ever has to be defined.

> Making those algorithms members of a class and making that
> class derived from String only adds dependencies and
> increases coupling.

Increasing coupling and adding dependencies is not neccessarily a bad thing, especially when it makes logical sense.

> > I don't see how using non-members is a superior
> approach
> > over extension classes. Nothing is saved by making the
> > function non-member functions, they are just scattered
> > throughout the namespace in a non-modular manner. It
> feels
> > like I am stepping back in time to old fashioned C ;-)
> Nothing has to be 'scattered', thats a bit of a loaded
> term. They can be grouped together in sub namespaces if
> you like.


> And you could be stepping sideways into the
> parallel universe of functional programming :-P

I wouldn't agree that functional programming is a parallel universe.

> > > There are a couple of other advantages to non
> members.
> > If
> > > someone has got a 'raw' String_Impl class or another
> > class
> > > statisfying the String interface, they cant use the
> > > methods of String_ext without creating a new
> String_ext
> > > fom the String_Impl. Doesnt this defeat the dynamic
> > typing
> > > goals that you have been working towards?
> >
> > Not really, I don't view dynamic and static typing as
> > mutually exclusive goals.
> I agree about dynamic and static typing. Thats why I was
> so interested in your 'Proposed Boost' Interfaces Library.
> And that is also why I've got a strong dislike of this
> String_ext class.
> Say I've got a class, YetAnotherString, which I'm using in
> lots of places. Say YetAnotherString statisfies your
> String interface. But I dont have a rich library of string
> algorithms like Concat(). If Concat was a nonmember
> function, I could just do this:-
> YetAnotherString foo(YetAnotherString fred,
> YetAnotherString bob) {
> OOTL::Concat(fred, bob);
> return fred;
> }

> And it would just work.

Well it would work if Concat was a template function.

template<typename String_T>
void Concat(String_T& x, const String& y)
// ...

Which I really don't like.

> With the String_ext approach I have to do this:
> YetAnotherString foo(YetAnotherString& fred,
> YetAnotherString& bob) {
> typedef OOTL::String_ext<YetAnotherString> YourString;
> YourString fred2(fred); //string is copied
> YourString bob2(bob); //string is copied
> fred2.Concat(bob2);
> return (YetAnotherString)fred2;
> }

Why would you not use YourString throughout?

typedef OOTL::String_ext<YetAnotherString> YourString;

YourString foo(YourString& fred, YourString& bob) {
return fred.Concat(bob);

> In fact I just wouldnt use it. By making these member
> functions you've massively limited the utility of your
> library.

I think that is a significant overstatement. The same could be said of any kind of information hiding. Some kind of restriction is desirable.

> Moral of the story. Dont use inheritance unless you need
> to, and I've given a checklist of when you might need to
> at the top of my post.

I strongly disagree.

Flat View: This topic has 16 replies on 2 pages [ « | 1  2 ]
Topic: Definite proDuctivity aDvantages Previous Topic   Next Topic Topic: Jumping from the top of The Parachutes

Sponsored Links


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