Choosing and applying the best design pattern for the particular problem

Started by
19 comments, last by nerijus ramanauskas 14 years, 1 month ago
Quote:Original post by rip-off
Quote:
Ok, if, suppose, I want to overload the cast operator (operator signed int())?

This is almost never a good idea. It can cause all sorts of subtle bugs.


And if I make it private (sorry, forgot to mention it), add some "friends" as well as static_cast (imagine it's just a template function that may be controlled by a user/developer), it will cause no sorts of problems.
Advertisement
Quote:Original post by nerijus ramanauskas
And if I make it private (sorry, forgot to mention it), add some "friends" as well as static_cast (imagine it's just a template function that may be controlled by a user/developer), it will cause no sorts of problems.


This just adds two more kinds of problems.

Sequence really is a problem solved completely by STL.
Quote:
...it will cause no sorts of problems.

It is your code base - you're the one who has to maintain it.

I'm not convinced you gain anything over having an explicit member function whose name describes the operation. Using static_cast is likely to take longer to write and still be less clear.

My impression from this thread is that you are maybe a little too eager to use some of the more obscure areas of C++, like implicit conversion operators and template specialisation, when there are clearer and simpler alternatives available. It might be worth thinking about what this buys you in the long run.
Quote:Original post by nerijus ramanauskas
The problem is that if I inhert the base class and if that class has some methods that return some new objects of the same class, return type won't change if I inherting that base class.

Well, since you are specifically asking for a pattern, I'm gonna mention the Curiously recurring template pattern ;-)
Ok, let's see:
template< typename Left_, typename Right_ >Left_ Convert< Left_, Right_ >( const Right_& Convert_ ){    return Left_( Convert_ );}class X{public:    // ...private:    template< typename Left_, typename Right_ >    friend Left_ Convert< Left_, Right_ >( const Right_& Convert_ );    /* unsigned char* */ operator unsigned char*( void );};

Let me see if there's a problem. /* global */ void /*::*/DoDoDo( unsigned char* ); DoDoDo( X() ); is not a problem, since it's not supported anyway if there's no explicit/public/etc cast operator.
My my! DevFred, almost there! Almost there! Let me see!
DevFred, this is really it! You've got a it! Danke!

I just, you know, hate STL and I think STL/C++ STD is extremely overdesigned. What I'm trying to do is to make it safe and clean to live in!

Extremely thankful for all you folks!
Have a nice day.
Yay, ok. Free functions meet the best. Will use them. But (just for greater curiousity) what if C++ was an absolute OO programming lang just like C# is? Free functions ain't exist. Would use static methods? Could think of a better choice. Huh?

Danke.
Quote:Original post by nerijus ramanauskas
Yay, ok. Free functions meet the best. Will use them. But (just for greater curiousity) what if C++ was an absolute OO programming lang just like C# is? Free functions ain't exist.
Thank God/Bjarne that ain't the case ;)
Though yeah you'd use static classes (you can pretend that the class owning the static methods is like a namespace in this case).
Quote:Original post by nerijus ramanauskas
But (just for greater curiousity) what if C++ was an absolute OO programming lang just like C# is?

Modern C# is not an "absolute OO" language either, it has functional ingredients as well. Being pure OO does not mean being good.

This topic is closed to new replies.

Advertisement