Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > C++ design/over desiging : stl style vs OOPS, OOAD

Reply
Thread Tools

C++ design/over desiging : stl style vs OOPS, OOAD

 
 
vincent.L
Guest
Posts: n/a
 
      09-22-2011
On 22 sep, 18:08, Stuart Redmann <(E-Mail Removed)> wrote:
> Stuart Redmann wrote:
> > > I find myself wishing for some way to tell the comiler that some
> > > template parameter should be of some class type. The only way to
> > > document this is to put in some comment in the template's description.

> Jorgen Grahn wrote:
> > Why would you place such a restriction? I know of no useful
> > characteristics shared by all class types, but no other types.

>
> I phrased that quite badly. Maybe I should try with the following
> example.
>
> class Base
> {
>
> };
>
> template<class T>
> class Mixin : public T
> {
>
> };
>
> What I want is a way to tell the compiler is that the type T of Mixin
> should be of type Base or derived from Base. There is probably some
> mechanism from boost, but that means that I have to read yet another
> book to make it work (and heaven forbids that one makes some mistake
> and has to wade a three-page long error message full of the innards of
> boost
>
> In my eyes the people behind boost are doing a terrific job of
> providing the functionality that should have been part of C++ right
> from the start. However, I remember that I read somewhere that the C++
> template mechanism was never intended (by Bjarne?) to do what nowadays
> is done by boost.
>
> Also there seem to be some slightly different interpretations of the C+
> + standard with regard to some corner cases of the language that
> should never be shown to the average C++ programmer but are essential
> to some template tricks in boost. That's why I rather do not use
> boost.
>
> Regards,
> Stuart



Most of Boost.TypeTraits has actually been included in the new c++
standard (C++11).
It is now part of the STL in the form of the type_traits header.

So your problem is actually easy to solve using standard C++ :


#include <type_traits>

class Base
{

};

template<class T>
class Mixin : public T
{
static_assert(std::is_base_of<Base, T>::value, "invalid type :
should derive from Base");
};
 
Reply With Quote
 
 
 
 
Keith H Duggar
Guest
Posts: n/a
 
      09-22-2011
On Sep 20, 12:09*pm, "(E-Mail Removed)" <(E-Mail Removed)>
wrote:
> Hello,
> * * *I am a bit confused about so many design approaches to even the
> simplest of problems. I am not able work with all of them together. It
> seems I have to pick one of these.
>
> Mainly there seems a distinct choice between the two.
> 1. The new generic programming way. All this stl algorithms, range
> functions, transforms, generates and function objects etc. *(This is
> my favourite for fun).
>
> 2. The object oriented, polymorphic, way. Say the trolltech QT
> framework. You really wouldn;t be approaching with style1 if you were
> to design something like QT. I guess.
>
> When do you do what. Can I say that if its a computation/algorithmic
> problem we are solving- style 1. If it is one of software design -
> style2. Is that true?


[snip]

Always strive for simplicity above all else. In other words, the
"MIT approach" (or if you are in a pinch fall back to WIB):

http://en.wikipedia.org/wiki/Worse_is_better

For example, for code prefer in this order

1) free function
2) free template function
3) member function

for data prefer in this order

1) constant
2) local variable
3) member variable

(the above post itself is highly simplified, just trying to give
you a very rough high-view idea/example).

KHD
 
Reply With Quote
 
 
 
 
Jorgen Grahn
Guest
Posts: n/a
 
      09-23-2011
On Thu, 2011-09-22, Stuart Redmann wrote:
> Stuart Redmann wrote:
>> > I find myself wishing for some way to tell the comiler that some
>> > template parameter should be of some class type. The only way to
>> > document this is to put in some comment in the template's description.

>
> Jorgen Grahn wrote:
>> Why would you place such a restriction? I know of no useful
>> characteristics shared by all class types, but no other types.

>
> I phrased that quite badly. Maybe I should try with the following
> example.
>
> class Base
> {
> };
>
> template<class T>
> class Mixin : public T
> {
>
> };
>
> What I want is a way to tell the compiler is that the type T of Mixin
> should be of type Base or derived from Base. There is probably some
> mechanism from boost, but that means that I have to read yet another
> book to make it work (and heaven forbids that one makes some mistake
> and has to wade a three-page long error message full of the innards of
> boost


I suspected that was what you meant to say. But don't you normally get
that feature automatically, since you're likely to get type errors if
you pick the wrong T when you instantiate the template?

Or, you could force the issue manually:

const Base& dummy = something_of_type_t;

> In my eyes the people behind boost are doing a terrific job of
> providing the functionality that should have been part of C++ right
> from the start. However, I remember that I read somewhere that the C++
> template mechanism was never intended (by Bjarne?) to do what nowadays
> is done by boost.


Sure, but that's not an argument against templates, is it?

> Also there seem to be some slightly different interpretations of the C+
> + standard with regard to some corner cases of the language that
> should never be shown to the average C++ programmer but are essential
> to some template tricks in boost. That's why I rather do not use
> boost.


If they are internal to the implementation, I don't mind. They can
implement Boost in microcode if they want.

I'm reluctant to use Boost myself, but that's more because much of it is
too complex to learn. Like Stroustrup writes:

"Sometimes, generality and simplicity coincide; in Boost, the
balance is IMO too often so far towards generality that novices
and average users are lost."

An average user who's lost. That's me when I read many of the
Boost documents.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
Werner
Guest
Posts: n/a
 
      09-26-2011
On Sep 22, 8:45*am, Stuart Redmann <(E-Mail Removed)> wrote:

> If have heard somewhere that the Qt re-implementation of containers
> has been done because (A) they were not satisfied with the STL
> containers,


This is not what I've heard. I've rather heard that at the time (of
original development) the STL was not portable enough (or that this
was their perception).

> and (B) they need an implementation that does not use so
> many template related technology. Argument (B) were due to the fact
> that they wanted to use Qt on the Nokia cell phone without having to
> develop a C++ compiler that is sophisticated enough to compile every
> template feature that STL code uses. I can't remember where I read
> this, probably some Qt forum.


Strange, as they use templates extensively in their own containers
too, apart from the fact that the containers in QT4 is to a large
degree STL algorithm compatible.

This is for instance the QT interface:

template <typename T>
class QList
{
//...
};

The only significant difference is the underlying memory management
(Qt not using allocators?).

Kind regards,

Werner
 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      09-27-2011
On Sun, 2011-09-25, Erik Engheim wrote:
....
> I favored generic programming for a while but after using it
> in practice I have come out against it. For the following reasons:
>
> 1. It doesn't scale. All the template stuff quickly make your
> compilation times unbearable. You might deal with that by hiding
> generic code inside cpp files and never expose them in your interface.
> Like e.g. VTK. But then you have taken away the ability to use generic
> programming as a way of defining your interfaces.
>
> 2. Error messages suck. I don't really think the elegance of the
> generic based solutions make up for time wasted in interpreting
> template error messages.
>
> 3. Really hard to debug. When you create say a for_each, with some
> bind2nd argument and a bunch other stuff, it is much harder to see what
> is going on in the debugger than with a regular index based loop.


I haven't seen your code, but it must be very different from mine:
I have none of those problems.

There are better and worse ways to use templates, just for any other
tool.

> 4. The average C++ developer doesn't get it. This potentially increase
> maintenance cost, because your average developer is not going to be
> able to read that code.


The average C++ programmer doesn't get C++, in my experience.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
persres@googlemail.com
Guest
Posts: n/a
 
      10-21-2011
So, I understand most people favor generic programming. Just as I
would have thought. c++0x, lambda etc have brought on a lot of
expressiveness and am hoping, if boost graph library and a lot of
others were rewritten today perhaps it might be much easier to use.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
a stl map which use stl pair as the key Allerdyce.John@gmail.com C++ 2 02-22-2006 07:25 AM
Copy elements from one STL container to another STL container Marko.Cain.23@gmail.com C++ 4 02-16-2006 05:03 PM
Need help with Style conversion from Style object to Style key/value collection. Ken Varn ASP .Net Building Controls 0 04-26-2004 07:06 PM
for mscir....others looking for help on desiging basic layout with css Richard HTML 8 04-09-2004 03:35 AM
To STL or not to STL Allan Bruce C++ 41 10-17-2003 08:21 PM



Advertisments