Though implementation problem

Originally Posted by Elysia

It's funny how you agree now. Functions that are generic and can do a lot of things are good. Very good. You agree.
Yet for my classes, I'd rather write high-level wrappers and put them as members. The members are merely wrappers for the generic function. You agree wrappers are good.

Had you actually made you position clear from the beginning (wrapping generic functions to provide cleaner interfaces) we could have avoided this whole time-waster.

To further add, I have never been against algorithms or powerful functions such as a generic one as you show, but the problem comes when you must use those in your code instead of higher level wrappers for simple functionality.

That's not really at all what you stated. You basically stated that the standard library has been ruined by generics.

Originally Posted by laserlight

That is a documentation problem, not a design problem.

Pretty much. But you know that some won't do it right, anyway. It's just sad.

I think that the correct approach is to put everything in the namespace, unless you want to emphasize the separation from the core interface of the class. Obviously, we are not back to plain C since the namespace mechanism is at work to avoid name collision.

I think namespaces are great, I really do. But they do not evolve code into something higher. What's good with classes? How about they can easily manage an internal state without littering around globals, how they can overload operators and can easily take care of their own resource management via constructors, copy constructors and destructors? The compiler will call them automatically for us, instead of we having to remember to call cleanup functions.
Namespaces do not contribute to that very much, I'm afraid, so without classes, it's like it's back to the good old C days.

So you would rather that std::string be a polymorphic base class? OOP really is about abstraction, encapsulation, inheritance and polymorphism via objects. OOP is not about classes and whether functions are member functions, static member functions, or non-member functions.

Well, then I don't know if there's a good work for putting members inside the class instead of outside :/

I think that is what you should do: provide wrappers to wrap the application of a generic algorithm to provide specific functionality that can be more easily used. That way, clients can enjoy both the flexibility of the generic algorithm and the quick access to the specific functionality. I believe this has been mentioned before.

Then here's my beef with the standard library: why are there still too much relying on algorithms? Is it simply lack of time or due to the committee's lack of money?

[QUOTE=brewbuck;752171]Had you actually made you position clear from the beginning (wrapping generic functions to provide cleaner interfaces) we could have avoided this whole time-waster.
True, true. Lack of communication. But I'm glad I can learn to agree with you.

That's not really at all what you stated. You basically stated that the standard library has been ruined by generics.

This is because I see algorithms, free functions and overcomplication everywhere.
I expect a replace function to seek and replace every instance of X with Y, but that's not what std::string::replace does and it frustrates me because these classes never work in a way I expect and need.

What's good with classes? How about they can easily manage an internal state without littering around globals, how they can overload operators and can easily take care of their own resource management via constructors, copy constructors and destructors? The compiler will call them automatically for us, instead of we having to remember to call cleanup functions.
Namespaces do not contribute to that very much, I'm afraid, so without classes, it's like it's back to the good old C days.

Classes versus namespaces is not a zero sum game. That classes can provide functionality that namespaces cannot do not point to a deficiency in namespaces, but to the fact that they have different use cases. I am not saying: prefer namespaces to classes. I am saying: use namespaces and classes (and free functions) appropriately.

Then here's my beef with the standard library: why are there still too much relying on algorithms? Is it simply lack of time or due to the committee's lack of money?

The reason is that the standard library is designed to cater to the users of a language, not the programmers of any particular application domain. The other reason is that design by committee often leads to half-way decisions due to compromises

Originally Posted by Elysia

This is because I see algorithms, free functions and overcomplication everywhere.
I expect a replace function to seek and replace every instance of X with Y, but that's not what std::string::replace does and it frustrates me because these classes never work in a way I expect and need.

Odd that you pick this example, since std::replace() (the fully generic version) would actually do what you're talking about. So this is an instance of a class simply not doing what you want it to do, not some disadvantage to generics.

Originally Posted by laserlight

Classes versus namespaces is not a zero sum game. That classes can provide functionality that namespaces cannot do not point to a deficiency in namespaces, but to the fact that they have different use cases. I am not saying: prefer namespaces to classes. I am saying: use namespaces and classes (and free functions) appropriately.

That just boils down to to having the functions split. Some in the namespace, some in the class, which is what I wanted to avoid in the first place :/

Originally Posted by brewbuck

Odd that you pick this example, since std::replace() (the fully generic version) would actually do what you're talking about. So this is an instance of a class simply not doing what you want it to do, not some disadvantage to generics.

True, obviously nothing at fault with the generics, simply lack of higher-level functions within the class, as you would expect when there's a fully generic function in the std namespace.
I just looked over the basic_string documentation in MSDN and I can tell it's incredibly confusing.
The standard library truly needs more higher-level functions...


But I cannot help but seem that the original question has yet to be answered...
Or the second one of splitting the implementation...
Wrappers are important...

Odd that you pick this example, since std::replace() (the fully generic version) would actually do what you're talking about. So this is an instance of a class simply not doing what you want it to do, not some disadvantage to generics.

To do Elysia justice, I don't think std::replace can do that (replacing substring for string), it can replace a character for another character. However, boost's string algorithms can do that and much more (alas, with free functions).

I expect a replace function to seek and replace every instance of X with Y, but that's not what std::string::replace does and it frustrates me because these classes never work in a way I expect and need.

But what if I actually want to replace a range for another?

As to the original question, can't you do something like this?

Code:

#include <iostream>

template <class T>
void convert(T n, T& m)
{
    std::cout << "no conversion really\n";
    m = n;
}

void convert( int n, float& f)
{
    std::cout << "converting int into float\n";
    f = n;
}

void convert( float n, int& i)
{
    std::cout << "converting float into int\n";
    i = static_cast<int>(n);
}

template <class T>
struct Number
{
    T value;
    Number(T t): value(t) {}
    Number<int> to_int() const { Number<int> n(0); convert(value, n.value); return n; }
    Number<float> to_float() const { Number<float> f(0.0); convert(value, f.value); return f; }
};

int main()
{
    Number<int> n1(10), n2(12);
    Number<float> f1(1.1), f2(2.2);
    n1 = n2.to_int();
    n2 = f1.to_int();
    f1 = f2.to_float();
    f2 = n2.to_float();
}

Originally Posted by anon

But what if I actually want to replace a range for another?

Oh sure, it's not like I'm saying it's bad or anything, but I never find functionality I need or expect.

As to the original question, can't you do something like this?

Well, I was just looking into making something like:

Code:

Strings::CTmplStringBase< char, Strings::StrTraits<char> > CharStr;
Strings::CTmplStringBase< wchar_t, Strings::StrTraits<wchar_t> > WCharStr;
CharStr.ToUTF16(); // OK, source is ANSI
WCharStr.ToANSI(); // OK, source is UTF16
CharStr.ToANSI(); // Illegal, no such member function
WCharStr.ToUTF16(); // Illegal, no such member function

I was trying out template specialization to do it, but as you see, I ran into trouble...
Since the definition returns the string class (which inherits from the definition), I must use a pointer or reference.
And secondly, the implementation also uses the class, further adding to the problem. I haven't found a way to separate the implementation from the definition (since the definition is in itself a specialized template class). Which was all discussed in the first post.

It would be cool, but otherwise I have to go for adding both members to the generic template and probably throw an error if the conversion can't be done.

O_o

Long<>Short: The same technique used by the Boost adder operator you are using can be used to do what you want. Instead of specializing on the element type of the string/container you need to specialize on the type of string. It is rather simple. The problem with this is that it changes the interface making the two/infinitely-many base classes incompatible. If you go this root you must separate your normal interface and your extended interface else it would not be very "OO" would it?

Also: 'ToUTF16' and 'ToANSI' are truly terrible names--for one there is character encoding called ANSI.

And you still fall into the design problem because of your misunderstanding of "OO" and silly prejudice. You argue that every function anyone might find useful should be part of the class--even if that means extending the class through inheritance, and at least in part you claim to argue this because "everyone will know where to look", but we recently discovered that really you only argue for this kind of thing because the syntax is sexy to your mind. The problem with this kind of logic is evident: it necessarily leads to innumerable classes with infinitely large interfaces exhibiting mutually incompatible behavior. Such a catastrophe of interface design invariably leads to unmaintainable crossing; such source is by definition not "OO".

Soma

Originally Posted by phantomotap

Long<>Short: The same technique used by the Boost adder operator you are using can be used to do what you want. Instead of specializing on the element type of the string/container you need to specialize on the type of string. It is rather simple. The problem with this is that it changes the interface making the two/infinitely-many base classes incompatible. If you go this root you must separate your normal interface and your extended interface else it would not be very "OO" would it?

Well, OO or not, what's good about C++ is that you aren't limited to one paradigm.

Also: 'ToUTF16' and 'ToANSI' are truly terrible names--for one there is no character encoding called ANSI.

Did you forget a "no" keyword in there?
If they are terrible names, what would you suggest?

And you still fall into the design problem because of your misunderstanding of "OO" and silly prejudice. You argue that every function anyone might find useful should be part of the class...

If it part of what the object does, then yes. Neatly organized.

--even if that means extending the class through inheritance, and at least in part you claim to argue this because "everyone will know where to look", but we recently discovered that really you only argue for this kind of thing because the syntax is sexy to your mind.

You might call it a bit of both.

The problem with this kind of logic is evident: it necessarily leads to innumerable classes with infinitely large interfaces exhibiting mutually incompatible behavior. Such a catastrophe of interface design invariably leads to unmaintainable crossing; such source is by definition not "OO".

This one strikes me odd, however. If classes cannot be extended indefinitely, how do OO people do it? Create several classes built around the same thing?


But come on, give me some slack here. C++ isn't just straight forward. I'm testing methods and ways of doing things. Without experimenting, you won't learn anything.
Surely there must be other people who do the same.

If it part of what the object does, then yes. Neatly organized.

By introducing so many member functions, you reduce encapsulation. You do not gain on organization since non-member non-friend functions organized in the same namespace also results in neat organization. You also do not gain on abstraction since the class' minimal but complete interface models the domain sufficiently.

This one strikes me odd, however. If classes cannot be extended indefinitely, how do OO people do it? Create several classes built around the same thing?

The non-member non-friend functions that we have mentioned is one way, though in some languages they would be static member functions of an auxiliary class instead. Composition (e.g., with the decorator pattern) is another way. Of course, it may be the case that inheritance is appropriate, so it depends on the situation.

Originally Posted by laserlight

By introducing so many member functions, you reduce encapsulation. You do not gain on organization since non-member non-friend functions organized in the same namespace also results in neat organization. You also do not gain on abstraction since the class' minimal but complete interface models the domain sufficiently.

But there are ways around that. One is to create a free member function and create a wrapper as a member.

The non-member non-friend functions that we have mentioned is one way, though in some languages they would be static member functions of an auxiliary class instead. Composition (e.g., with the decorator pattern) is another way. Of course, it may be the case that inheritance is appropriate, so it depends on the situation.

So another way might to break up the class into several smaller classes where the interface is easier to manage and then simply inherit them into one big class? That sounds like it would squash the problems with big classes, yet let you use a big class.

1. A program that is not extensible has a polynomial (e.g. n-squared) amount of time required to add a new feature. For each new feature you must also reimplement many existing components.
2. A program that is extensible has a linear amount of time required to add a new feature. For each new feature you add you must implement it for each class.
3. A program that contains reusable code requires a sub-linear (possibly constant) amount of time required to add a new feature. You implement the feature once and you're done - it works with almost every other component automatically.

That's knowledge I gained form a course some time ago.

The algorithms provided by the std library for example, put programming in the last category. You however, are at best always designing your programs aiming at option 2. As your program size doubles, the amount of work required to add a new feature roughly doubles. It may seem good to you now because it's much better than option 1. However, continue the way you're going and you'll never succeed at a large scale project.
I work on a project with over half a million lines of code, every day. If we were only aiming for an extensible program then we wouldn't have gotten this far, and still be able to maintain it easily.
You've got to see the big picture.

Wait, some of that seems contradicting.
Option 2 means adding higher level functionality to your program. It takes roughly double the time. But they are, I guess, mostly free functions, as to be able to reuse code for other classes.

Then I take it option 3 means you go the way of the standard library. Lots of low level functionality and algorithms. Much code reuse, but little programmer friendly, so it becomes hard to maintain.

Only creating member functions will lead to option 1.

So the aim is to go for option 2 - try to put as much functionality as you can as free functions, and wrap those via higher level functions possible. This might mean high level free function or high level member functions, depending on what is appropriate.
Since classes can be come a chore when growing bigger, it is best to put functionality outside and create wrappers inside, and possible make several smaller classes and derive them into one bigger class, if you want.

The picture I'm seeing is that it might just give the best of both worlds with as little sacrifice as possible (there will, of course, be no perfect solution, but as I see it, it's a small sacrifice that won't do that much harm).

One is to create a free member function and create a wrapper as a member.

I assume that by "free member function" you mean "free function". A member function wrapper still has access to the class internals, and can cease to be a wrapper after maintenance. In other words, you do not increase encapsulation by providing syntactic sugar.

So another way might to break up the class into several smaller classes where the interface is easier to manage and then simply inherit them into one big class? That sounds like it would squash the problems with big classes, yet let you use a big class.

Are you referring to one approach used in Java: the use of multiple inheritance with pure interfaces? If so, I think that this is less useful in C++ due to the template mechanism, particularly so when the C++0x concept of a concept comes into play.

Originally Posted by laserlight

I assume that by "free member function" you mean "free function". A member function wrapper still has access to the class internals, and can cease to be a wrapper after maintenance. In other words, you do not increase encapsulation by providing syntactic sugar.

Yes, I meant free function, of course.
But if the wrapper member starts to divulge from the free function, it means the free function must be updated, as well, since seeing as if there was no member from the beginning the functionality that is required simply doesn't exist.

The concept of free functions is to increase encapsulation and to protect the class against changes, and to increase code reuse...
So what are the purposes of member functions? To provide the functionality that the free members lack?

Are you referring to one approach used in Java: the use of multiple inheritance with pure interfaces? If so, I think that this is less useful in C++ due to the template mechanism, particularly so when the C++0x concept of a concept comes into play.

Yes, the java method... but C++0x seems to add some more things that would require a little reschooling when it comes out and is supported I think.
I don't know very much about the feature, paradigms or the like that will show up in C++0x.