How properly inherit from template?

**anon** · 04-24-2008

Originally Posted by Elysia

Perhaps it is, but they should both do the same thing (if the algorithm is used in such a way) and the to_lower member is simply less to type and therefore preferred (also less error prone).

I would like to point out that the free function to_lower requires you to type one character less than the member function string::to_lower (or generally any free function vs member function), namely the dot character.

Now, if an API provided a key_exists function for containers with find member, exactly how does the following not abstract the algorithm away for the user less than a member function of set, map etc. would?

Code:

template <class Container, class Type>
bool key_exists(const Container& c, const Type& t)
{
    return c.find(t) != c.end();
}

Edit:

Free functions are simple "worse" (if you could call it that), because it's exactly that - free. It's not a member function.

Yeah, in Western society the word "free" has clearly negative connotations. Anybody should see immediately that free things are bad.

**Elysia** · 04-24-2008

Originally Posted by anon

I would like to point out that the free function to_lower requires you to type one character less than the member function string::to_lower (or generally any free function vs member function), namely the dot character.

But that argument is only valid for algorithms... not for member function vs free function...

Now, if an API provided a key_exists function for containers with find member, exactly how does the following not abstract the algorithm away for the user less than a member function of set, map etc. would?

Code:

template <class Container, class Type>
bool key_exists(const Container& c, const Type& t)
{
    return c.find(t) != c.end();
}

But this wasn't the point. It's clearly better than doing it manually, but it's worse from doing Container.key_exists directly. It's just a step below.

Edit:

Yeah, in Western society the word "free" has clearly negative connotations. Anybody should see immediately that free things are bad.

Lol no, I think not. Free functions are bad only in C++

Oh and as for java... It has a garbage collector, and is darn slow aside from that because it's interpreted and... I think java does not support multiple inheritance?
Garbage collector = evil, slow = nightmare, !"multiple inheritance" = nightmare

**laserlight** · 04-24-2008

Free functions are simple "worse" (if you could call it that), because it's exactly that - free. It's not a member function.

Why are free functions worse than member functions?

Error prone was directed at algorithms. One wrong arguments and could go to oblivion, while you could simply call the to_lower() member function with one or no arguments, and then it would be much less prone to errors or mistakes due to the programmer.

Or you simply call the to_lower() free function with one or two arguments, "and then it would be much less prone to errors or mistakes due to the programmer".

**brewbuck** · 04-24-2008

Originally Posted by laserlight

Why are free functions worse than member functions?

I think Elysia has had too much OO Koolaid. Objects aren't everything.

In case people have not noticed, C++ is quickly moving in a powerful direction, guided by generic programming, algorithmic and data abstraction. Notice the lack of the word "object" in the preceding sentence.

If classes were completely removed from C++, it would still be just as powerful as before, but with an uglier syntax (you'd just do OO the "C way"). Whereas removing templates and free functions would cripple it.

**Elysia** · 04-24-2008

Originally Posted by laserlight

Why are free functions worse than member functions?

To your question, a quote:

Originally Posted by Elysia

It's not more complicated, but it defiles the way of having the object perform the action.
The first example is like using a car to drive it into place while the second way is like tossing your car keys to someone else and saying "Hey you! Drive that car into the garage!".
(While you may or may not trust that someone is out of context here.)

I prefer to do it myself. The string itself should make itself lower. It knows best itself how to do it anyway.
I don't like utility functions that do it an indirect way.

Or you simply call the to_lower() free function with one or two arguments, "and then it would be much less prone to errors or mistakes due to the programmer".

Yarr. Member function > free function -> algorithm.

**laserlight** · 04-24-2008

To your question, a quote:

In other words, you consider free functions worse than member functions because you are uncomfortable with the syntax. Thus, your argument is not an objective technical argument, but an opinion based on personal taste.

**Elysia** · 04-24-2008

They've all been.

**anon** · 04-24-2008

But this is not a valid argument. Consider a string that gives you access to individual characters. Surely you are tempted to use this access, to implement free functions or member functions of other classes. Surely this is error-prone. Surely the string class is giving away the car-keys by letting you do things with the characters.

But I think this argument is mixing up too many things. Firstly, it seems that algorithms is too low-level for you (using transform for case conversion is indeed not a very good thing to do, moreso because the tolower function doesn't work with the "right" types). Free functions vs member functions is a completely unrelated argument, and here you are just claiming that one is better than other.

I also get the feeling that you like to roll your own things because this way you wouldn't have to learn the usage of libraries written by other people (you wrote it, you know it all). Everyone else would still have to learn the usage of your string etc.

**laserlight** · 04-24-2008

They've all been.

The argument that member functions are tightly coupled to the class whereas free functions that are not friends reduce coupling is not mere opinion based on personal taste, but one seen to be true by observation. One can reason that tight coupling gives less flexibility to changing the interface, which in turn means more difficult maintenance and extension.

I think I have cited some of the literature to you :|

**phantomotap** · 04-24-2008

YOG SOTHOTH! I hate this forum! I had this lovely post typed... *sigh*

Now I'm just going to respond to the new stuff plus this:

Do you know better how to meow than cat, for example? If you do, then there's something wrong with that cat. For the cat, sounding like that is natural behaviour, and so member functions should be natural for the object. Therefore, in sense, they should know best how to perform a task on itself.

This is nonsense. I've never said that objects should be bare. All objects will naturally have behaviors that only the objects will be capable of performing correctly. All objects will naturally have state that only the objects will be capable of manipulating correctly. This, however, is not what you are arguing. You are arguing for far more than this. Quite simply: do you know better how to sing "Music of the Night" than a cat?

Lumping behavior and state with an object simply because you find the source more appealing is just plain wrong.

Lumping behavior and state with an object because you want intellisense to do your job is just plain wrong. (Nothing wrong with using tools to make your job easier, but if the tools are the deciding factor in the design you need to get better tools.)

It's clearly better than doing it manually, but it's worse from doing container.key_exists directly.

Nonsense. With a freestanding function I can absolutely depend on the mechanism being implementable with an appropriate named, stable interface regardless of the container source. (Yes, you may have to decorate the name, and the function may require the use of a method, but the decorated name will be stable.) With the method version I have to rely on the programmer to provide the exact method. If one doesn't provide the exact method I must re-implement the target source. If the programmer changes the method interface I must upgrade the target source. However, with just a little extra forethought the freestanding function has insulated me from changes. I have increased encapsulation. (As... someone said, LL?!, "less typing" is a pointless metric. Just in case there is an example.)

Code:

container.key_exists(data);
key_exists(container,data);

Whereas removing templates and free functions would cripple it.

And I, for one, would be programming in Ada.

But I think this argument is mixing up too many things. Firstly, it seems that algorithms is too low-level for you (using transform for case conversion is indeed not a very good thing to do, moreso because the tolower function doesn't work with the "right" types).

It seems to me his problems with algorithms is, their greatest feature, that they are too generic. (And as you said, he is lumping many issues together.) His only arguments favoring methods over "std::algorithms" seem to be that they are difficult to use correctly. Naturally of course, a "one trick pony" will be easier to use correctly and something as generic as 'std::transform' will be more difficult even if it is presented as a member function.

Anyway, using 'std::transform' is fine for transforming a string to lower case. The trick is not using 'char'/'wchar_t' based strings and the C inherited 'std::tolower' as the transformation function.

Soma

**medievalelks** · 04-24-2008

Originally Posted by laserlight

The argument that member functions are tightly coupled to the class whereas free functions that are not friends reduce coupling is not mere opinion based on personal taste, but one seen to be true by observation. |

How is string::to_upper() anymore coupled to string than to_upper(string s); ?

**CornedBee** · 04-24-2008

Code:

template <typename StringLike>
StringLike to_upper(const StringLike &s);

This one's less coupled.

**medievalelks** · 04-24-2008

Originally Posted by CornedBee

Code:

template <typename StringLike>
StringLike to_upper(const StringLike &s);

This one's less coupled.

How would you implement that on a generic type?

to_upper<Beeble>(myBeeble); // does what?

**phantomotap** · 04-24-2008

How is string::to_upper() anymore coupled to string than to_upper(string s); ?

(Assuming this "'string'" is provided by a third party...)

If 'string' has some method of element reads and writes I can implement 'to_upper(string)' myself.

I can't implement 'string::to_upper()' unless I inherit. (And then it would be 'my_string::to_upper()'.)

I can distribute 'to_upper(string)', by itself, in any form.

The 'string::to_upper()' must be a part of the declaration of 'string' and probably must be packaged with the rest of the methods.

There are more of course, but I figure these as the most important problems/distinguishing traits with coupling.

Soma

**anon** · 04-24-2008

Originally Posted by medievalelks

How would you implement that on a generic type?

to_upper<Beeble>(myBeeble); // does what?

A string could be represented in many ways. Boost's case conversion functions accept a StringLike, it works for null-terminated char arrays, std::string, std::vector<char> etc.

It doesn't mean it should have any meaning for Beeble.