Thread: How properly inherit from template?

Originally Posted by anon

Ouch. I though the algorithms library was the most OOP part of standard libraries - container objects interacting with contained object interacting with predicate objects etc. If you use it to the full, the calls might look a bit more verbose and a bit less readable than ideal, but I don't see how the problem comes from the algorithms being free functions (the most complicated part is the predicates). And do you find it bad that you can also sort arrays, not just vectors?

Algorithms make it more complicated in way that you have to remember them and utilize them. It's far easier to just call a member function and let it do the algorithm for you. I like abstracting away things.
And unfortunately, I have never sorted an array or vector (or at least never via sort algorithms), at least for what I can remember.

Would you say that given the two following options the second is poor programming?

Code:

string s;
s.to_lower(); //hypothetical member function
to_lower(s); //boost/algorithms/string.hpp

Exactly how is the second way more complicated?

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.

I like typical .NET/VB style frameworks. Everything is organized neatly into classes who has member functions to do things. It makes it easier to use (you know what functions exists directly and can use them w/o consulting the manual to find an appropriate utility function), less headache to find functions and use them, as well.

Algorithms make it more complicated in way that you have to remember them and utilize them. It's far easier to just call a member function and let it do the algorithm for you. I like abstracting away things.

hmm... but a generic algorithm is the next step in abstraction after abstracting away an algorithm implementation into a function, be it a member function or a free function.

Originally Posted by Elysia

Algorithms make it more complicated in way that you have to remember them and utilize them. It's far easier to just call a member function and let it do the algorithm for you.

Why are algorithms harder to remember? Wouldn't it be just as hard to remember all the member functions. What about user-defined predicates (the only thing I find hard about using algorithms)? Would you have a large amount of very specialized member functions instead? (Some higher-level functionality would be welcome by me, though, but the ability to use existing algorithms with user-defined predicates is pretty important.)

I like abstracting away things.
using t

Algorithms seems to be more abstract than what you seem to like.

And unfortunately, I have never sorted an array or vector (or at least never via sort algorithms), at least for what I can remember.

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.)

Given this attitude, no object should have any public interface at all. Otherwise, who knows, someone might use it to implement additional functionality...

I like typical .NET/VB style frameworks. Everything is organized neatly into classes who has member functions to do things. It makes it easier to use (you know what functions exists directly and can use them w/o consulting the manual to find an appropriate utility function), less headache to find functions and use them, as well.

Everything is not a class in C++. Don't you like that the same to_lower function can also convert plain C-style arrays?

Originally Posted by anon

Why are algorithms harder to remember? Wouldn't it be just as hard to remember all the member functions.

Because you must remember what they are and what they do. It's like math. You learn algorithms and then forget them. Remember a function name that is easier to call is easier and is part of the class.

Would you have a large amount of very specialized member functions instead? (Some higher-level functionality would be welcome by me, though, but the ability to use existing algorithms with user-defined predicates is pretty important.)

Yes. If they abstract away the use of an algorithm, absolutely.

Algorithms seems to be more abstract than what you seem to like.

Yes, they do take away complexity, but they are still lower than appropriate member functions that applies an algorithm on the object itself.

Given this attitude, no object should have any public interface at all. Otherwise, who knows, someone might use it to implement additional functionality...

I was not talking about trust. That's irrelevant. I was merely talking about how the two uses resulted in a different path to achieving the same thing.
Of course, you probably wouldn't just say that to anyone, but a professional who worked with doing this sort of thing. Someone who's job it is to do so, just as it is the function's job to do so.

Everything is not a class in C++. Don't you like that the same to_lower function can also convert plain C-style arrays?

Well, if you ask me, C-style strings should be avoided (they should not be removed, because they are necessary for critical speed). They should be encapsulated inside a class which gives it its functionality. And in such a way, it should have a to_lower member function.

But also, there's nothing wrong with a free to_lower function, but you should not have to call it on an object. The object's member function, could, however, call the free to_lower if it wanted.

Because you must remember what they are and what they do. It's like math. You learn algorithms and then forget them. Remember a function name that is easier to call is easier and is part of the class.

But all the generic algorithms are functions (or rather, function templates).

Yes. If they abstract away the use of an algorithm, absolutely.

Yes, they do take away complexity, but they are still lower than appropriate member functions that applies an algorithm on the object itself.

That is true: a generic algorithm would typically be used to implement a domain specific algorithm, which would itself be given an appropriate name as a function, and it is this function that should be used when using the domain specific interface, not the generic algorithm. But that is different from saying that generic algorithms should be avoided. Rather, we should use what is most appropriate for a given level of abstraction.

But also, there's nothing wrong with a free to_lower function, but you should not have to call it on an object. The object's member function, could, however, call the free to_lower if it wanted.

That does not make sense: as you pointed out, the string object would know better how to implement to_lower. Likewise, consider: we typically implement a free function swap for a given type using its member swap, but not the other way round (though we may use free function swaps to swap the members of that class' objects).

Originally Posted by phantomotap

Why? I have no problem reinventing the wheel, but only if something is gained. What is gained from doing it yourself if you already have a generic solution?

Well, for me, firstly it's easier to find that function. It's part of the class. No need to search for some utility namespace or utility function for class X.
And secondly, it makes the code look neater and better to me.

So, to your mind, every string implementation ever written should have unique and thorough knowledge of every character encoding and language ever spoken/written? That seems a little excessive.

There are always pitfalls, true... But (provided you have access to the source) if you make a free function to do the work, why not make it a member function?

Define "best"! Even with whatever definition, it would know "best" only if it is programmed with that knowledge.

Since the member function should emulate the object itself, then it must know best, or the object itself is flawed.
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.

With this logic in mind, to extend an implementation to support 'tolower' for a new encoding or for a new language you would have to inherit/re-implement creating yet another string type that would need to be "remembered". Do you think that would really be better than an outside mechanism?

No, in this case, a utility function is clearly better. But it doesn't mean I like it
Indeed, I am planning on writing my own string class because std::string is too lacking and MFC's CString doesn't support integer conversion (and split, etc) and neither are very derive friendly. It's life, sadly.

[edit] for clarity, that was directed at phantom but my net keeps being screw[/edit]
Well I have to say, I disagree on so many levels I am experience disagreement overload. First off, when we all started we wanted to reinvent every wheel. "Oh strstr() does this? I will write one! to_upper() does what? I will make one too!" Then eventually you stop reinventing wheels because its a waste of time and you gain nothing but experience... experience you could have gained writing something new. But like I said, everyone seems to be like that when they are first learning..

As far as inheriting things over and over again, that is what templates are for.... that and just the shear act of not overriding functions.

On one final note, intellesense has made it unimportant for any novice to have to know jack about any object.

Originally Posted by laserlight

But all the generic algorithms are functions (or rather, function templates).

But you usually don't have to remember how to use them
Compare that to_lower example with transform vs a to_lower member function. I'd say the to_lower member function is easier to remember and less to type and looks neater and is easier to read

That is true: a generic algorithm would typically be used to implement a domain specific algorithm, which would itself be given an appropriate name as a function, and it is this function that should be used when using the domain specific interface, not the generic algorithm. But that is different from saying that generic algorithms should be avoided. Rather, we should use what is most appropriate for a given level of abstraction.

I agree. The point was that I wanted to make a member function specific so I could call that instead of the algorithm.
Algorithms are invented for a reason and you should use them as appropriate, but I would consider adding member functions that use the algorithms instead of directly using them, however.

That does not make sense: as you pointed out, the string object would know better how to implement to_lower. Likewise, consider: we typically implement a free function swap for a given type using its member swap, but not the other way round (though we may use free function swaps to swap the members of that class' objects).

But if the implementer also made that free to_lower function, then the implementer knew that function well and could decide in the implementation if to call that, if it were to be appropriate for the implementation.
If the implementer did not create it or didn't know it, then he or she would have to decide if it was worth doing their own algorithm or code to do it or if the free function could suffice.
The implementer knows best and should decide what's actually best for the object itself.

Originally Posted by master5001

Well I have to say, I disagree on so many levels I am experience disagreement overload. First off, when we all started we wanted to reinvent every wheel. "Oh strstr() does this? I will write one! to_upper() does what? I will make one too!" Then eventually you stop reinventing wheels because its a waste of time and you gain nothing but experience... experience you could have gained writing something new. But like I said, everyone seems to be like that when they are first learning..

Heh, but even as an experienced developer, I seem to hate how the C++ utilities are spread out. I don't like typing 50 lines of code to shut down Windows or such. I don't like how it's organized. I want it my way. So as an experienced developer, I can now reinvent the wheel on my free time to make the language more to my liking.

On one final note, intellesense has made it unimportant for any novice to have to know jack about any object.

Which is why it's so easy to make a member function. You'll spot it via intellisense and away you go with the code. You don't need to check the manual for an appropriate utility function.

Compare that to_lower example with transform vs a to_lower member function. I'd say the to_lower member function is easier to remember and less to type and looks neater and is easier to read

But that is comparing apples to oranges: an implementation versus an implemented function. A better comparison is boost::algorithm::to_lower to a member to_lower, which is precisely anon's example.

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).

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).

If there was no need to fully qualify the name (e.g., the appropriate using directives were used), then the free function version is "less to type":

Code:

to_lower(x);
x.to_lower();

But "less to type" is an invalid argument to begin with.

So, how is it "error prone"?

Originally Posted by laserlight

But "less to type" is an invalid argument to begin with.
So, how is it "error prone"?

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

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.