Thread: How properly inherit from template?

Originally Posted by phantomotap

Precisely, but I wonder, what exactly is your point? It is after all a tool? Are you saying we shouldn't use it?

Not at all. I'm saying to spare me the pulpit speeches about a "new revolution" and that a bunch of blind sheep are somehow "missing the boat".

OK, first of all... A lot of you see to be going on how free functions increase encapsulation. I don't disagree. Free functions can be ore flexible.
I don't like free functions, however. I like member functions before, if possible. In my opinion.

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

You have. I can bust one thing, however.
Free to_upper won't need to change as long as the public interface does not change. But that means we can make a member function that uses common interfaces that do not change or use the public interfaces to get the data. Not the most efficient, but it works just the same as the free function.

As for the other... well, free functions can still be better.
But even if there was just as member function that called the free function, I'd be happy. Solution for both worlds.

Originally Posted by phantomotap

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?

I am saying that an object's member function should always know how to perform some task better than a free function. If the free function is better, then there's something wrong with your implementation of the member function.

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

As I mentioned above, member functions can still work fine if you change the interface. Nothing different here with those and free functions. Free functions are good for other things, especially algorithms.
And it's not about intellisense. In this case, intellisense simply makes easier even easier.

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

To this I simply respond the same as above. This isn't about less typing, but that the object should do it, not someone else.

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.

Yes, they are more error prone, harder to read and the object isn't doing the work, someone else is.
That's all.

Free to_upper won't need to change as long as the public interface does not change. But that means we can make a member function that uses common interfaces that do not change or use the public interfaces to get the data. Not the most efficient, but it works just the same as the free function.

That's true, as long as the extra member functions do not use anything non-public they will have the same advantage in loose coupling as non-member non-friend functions. Likewise, you can always make all the members public, and as long as no one breaks the documented rules, everything will be fine and dandy (and it can be somewhat fine and dandy, e.g., in C or PHP 4).

In fact, that is a form of coupling.

Nope. Not in the programming world. I can freely create a binary, say a DLL, requiring an interface that may never exist. I can freely create a template that requires an interface that may never exist. This isn't coupling or lack of coupling to my mind, but something else entirely. (I might should mention that this was in response to your repeated "but the interface must be available" in response to "package distribution".)

No, that's not what I have claimed and is orthogonal to what we were discussing.

Coupling in the nature of C++ programming is basically all I have been discussing for some time. I have no idea what you are discussing, but you should perhaps stop responding to me if you aren't discussing this topic. (Or, alternatively, you might do more to explain what you are discussing and who you think you are discussing it with.)

Free to_upper won't need to change as long as the public interface does not change. But that means we can make a member function that uses common interfaces that do not change or use the public interfaces to get the data.

Nonsense. You can say a 'to_upper' method won't need to be changed. That isn't the point of making and using freestanding functions over methods. One goal is to insulate yourself from changes. That changes may not occur is irrelevant; what if change happens? (Obviously, a no parameter 'to_upper' would likely never change in interface. Changes in a mechanic however...)

I am saying that an object's member function should always know how to perform some task better than a free function. If the free function is better, then there's something wrong with your implementation of the member function.

Nonsense. If there exists a correct, complete implementation for some mechanic then the public method and freestanding function must be same--or one is lacking in correctness or completeness. If the freestanding function, complete and correct as above, can exist then the only thing you might possibly gain compared with a method is typing a few less characters.

With your logic, you must inherit from 'cat' to introduce a new type 'cat_what_can_sing'. Now, obviously, again with your logic, 'cat_what_can_sing' can't just provide an additional interface for implementing freestanding 'sing_song' functions; instead, you must introduce yet another typed named 'cat_what_can_sing_music_of_the_night' providing the method 'sing_music_of_the_night' that 'cat_what_can_sing::sing' might call. All I can say is: Gods help you if you want the thing to sing more than one song. >_<

As I mentioned above, member functions can still work fine if you change the interface. Nothing different here with those and free functions. Free functions are good for other things, especially algorithms.

False. I have no idea why you responded with this. As has been said, if, for whatever reason, you decide to change the interface of your method, I must change the target source. I can keep the target source unchanged if I write it with a freestanding function to begin with precisely because I can control the freestanding function. They are obviously very different.

To this I simply respond the same as above.

In which case, you didn't address anything, at all, in the quote associated with this response.

Yes, they are more error prone, harder to read and the object isn't doing the work, someone else is.

Nonsense. They, that is to say the use, are not more error prone than any alternative. (A large number of "one trick ponies" is not an alternative to a generic function, method or freestanding.) That the object isn't "doing the work" is a tremendously odd statement. (If the method only serves to call other methods or freestanding functions the different is entirely syntactical.) With "harder to read" being subjective entirely.

Anyway, I have to ask: In my library there are no freestanding functions, only objects--"functiods"--that must be instantiated; who/what "does the work"? I mean, my variant of 'std::copy' creates an instance and invokes my variant of 'std::assign' repeatedly which in turn may call a virtual copy constructor of some object, for example. (A long story involving disheartening tales of caching, exception requirements, threading goals, and the all important interface dreams. My 'std::vector', for example, "behaves" "correctly" for 'std::vector<some_type &>' in the face of threading, exceptions, and manages to be pretty fast all the same.)

I wonder if I hit the proverbial nail on its' head.

He has claimed that it isn't just typing and inferred that it isn't syntactical sugar. I wonder...

Soma

Originally Posted by citizen

Are you suggesting that a generic algorithm is never suited to a task? At face value, this statement can be too absurd. For example, what if you had a list of some objects, and you had to copy the list into a better data structure for other processing (such as searching), like a tree?

No, no. OK, I'm trying to set things right here.
Algorithms:
- Good in sense that they can perform tasks so that you don't need to rewrite code that does the same thing on multiple objects.
- Error prone in sense that it may require a couple of arguments and they must be right.
- Lessens readability because an algorithm is not an easy thing to some and especially those who do not know the algorithm or what it does.

Free functions:
- Good in sense that they are not limited to one object - they can work with multiple string classes, say, given they have the right interface.
- Increase encapsulation.
- More readable than algorithms.
- Bad in that this is the "the classes themselves does not do the work" analogy (I'll explain that later).

Member functions:
- The objects themselves perform the work.
- Most readable of all three.

And the "the class does all the work" or not... if you call a free function, then the function is doing the work. If you call a member function, the class does the work.
It's not about where the code goes or how it works, but about who you are assigning to make it work. The function you're calling. It doesn't matter if the member function to_lower calls the free to_lower--that's implementation issues which are always hidden from the outside.

I mean, just because you're an expert in some profession doesn't mean you can't hire someone to help. So whatever happens after you call a member function doesn't matter the slightest. The implementation in a class is hidden to the outside - as it should be. We don't know what happens inside nor should we care. That's the class's out business.

You state that you prefer a logical breakdown:
methods -> free functions -> generic algorithms

How aggressive are you in persuing your best approach? Are you rebuilding the STL with algorithms as classes?

Am I? Yes and no, to an extent. No, I'm not rebuilding any STL classes per se, but I am building a big framework myself. Mostly I've been reorganizing and encapsulating C stuff (like Windows API), but I'm also planning on writing my own string class because the existing ones are lacking.

Seriously, like:

binary_search< item, value > test( ).go( );

I don't know if I would do that. It's constructing the item. That's the work of the constructor, is it not?

Would you recommend this? Perhaps I'm just a bit comfortable with what I know but I don't see the same glaring error that you do, exactly. I point out that foo.bar() is essentially the same as bar( foo ); the difference is in syntactic sugars. bar is not necessarily a free function, at least, if you've ever used python. I don't think there is a valid argument there and if we are to assume that your whole critiscism of the STL is based on syntactic sugar, than you're a silly goose. Programming is much more than syntax.

It's not about the syntactical that I'm hung over, but it's more of the idea who does the work. The free function or the class? If it's a class that you're working with, then the class should do the work, if possible. Because we're breaking the concept that a class is an object with free functions. In that I mean, the object should do all the work - you shouldn't tell someone else to tell the object to do it.
And the object itself can do the things better than a free function because it has access to its private members and internal workings. So the object can always be more efficient, at the cost of some encapsulation.

Originally Posted by phantomotap

Nonsense. You can say a 'to_upper' method won't need to be changed. That isn't the point of making and using freestanding functions over methods. One goal is to insulate yourself from changes. That changes may not occur is irrelevant; what if change happens? (Obviously, a no parameter 'to_upper' would likely never change in interface. Changes in a mechanic however...)

Not nonsense. What the free function does is just take an extra argument and call the public interfaces. I could just as well create a member function that takes no extra arguments and uses public interfaces.
This completely eliminates the advantage of making it freestanding for this argument.
However, they are good for other things - especially not requiring to implement the same methods into all classes since a free function can work over multiple classes.
(But then again, you could just copy the member functions over to the other classes. If they use public interfaces, no changes needs to be made. This is, of course, assuming that the member function and the free function uses the same functions, in which case both would work or both would fail.)

Nonsense. If there exists a correct, complete implementation for some mechanic then the public method and freestanding function must be same--or one is lacking in correctness or completeness. If the freestanding function, complete and correct as above, can exist then the only thing you might possibly gain compared with a method is typing a few less characters.

Indeed, but the object would do the work, as it should.

With your logic, you must inherit from 'cat' to introduce a new type 'cat_what_can_sing'. Now, obviously, again with your logic, 'cat_what_can_sing' can't just provide an additional interface for implementing freestanding 'sing_song' functions; instead, you must introduce yet another typed named 'cat_what_can_sing_music_of_the_night' providing the method 'sing_music_of_the_night' that 'cat_what_can_sing::sing' might call. All I can say is: Gods help you if you want the thing to sing more than one song. >_<

So sue me. I like it better with objects. Within reasonable limits, I will reinvent the wheel.

False. I have no idea why you responded with this. As has been said, if, for whatever reason, you decide to change the interface of your method, I must change the target source. I can keep the target source unchanged if I write it with a freestanding function to begin with precisely because I can control the freestanding function. They are obviously very different.

Untrue. See above.

Nonsense. They, that is to say the use, are not more error prone than any alternative. (A large number of "one trick ponies" is not an alternative to a generic function, method or freestanding.)

How is algorithms not error prone? Unless you know how to use them, which is harder than normal member function OR free functions, they WILL go wrong.

That the object isn't "doing the work" is a tremendously odd statement. (If the method only serves to call other methods or freestanding functions the different is entirely syntactical.) With "harder to read" being subjective entirely.

Anyway, I have to ask: In my library there are no freestanding functions, only objects--"functiods"--that must be instantiated; who/what "does the work"? I mean, my variant of 'std::copy' creates an instance and invokes my variant of 'std::assign' repeatedly which in turn may call a virtual copy constructor of some object, for example. (A long story involving disheartening tales of caching, exception requirements, threading goals, and the all important interface dreams. My 'std::vector', for example, "behaves" "correctly" for 'std::vector<some_type &>' in the face of threading, exceptions, and manages to be pretty fast all the same.)

I addressed that above. Have a read.

Speaking of coupling, suppose we have a class A and we want to add some functionality that can be implemented in terms of the public interface. Suppose we have two users "first.cpp" and "second.cpp" and only the second user wants to use the new functionality. Which is better, change A and force both users to recompile or add the functionality as a free member in a new header file and recompile only the second user which includes this header?

I was discussing the difference between string::to_upper and to_upper(string)

In case of boost::to_upper, it is generic and in no way coupled with std::string. It doesn't accept a std::string, it accepts a WritableRangeT.

Elysia, when you are saying that it's better if the class does the work, do you really think the best strategy is to put everything that anyone might want to use a class for in the class? Ok, lets say I want vector::random_shuffle and deque::random_shuffle. Then I might also want vector::increment_by_one and list::erase_every_second_item. Etc. Does it not seem that at some point you'd have to say no, because the required functionality is too specific and the user should implement it themselves. A class simply cannot cater for all conceivable needs.

So, what you can only argue about is that the C++ standard libraries say no too early.

Originally Posted by anon

Elysia, when you are saying that it's better if the class does the work, do you really think the best strategy is to put everything that anyone might want to use a class for in the class? Ok, lets say I want vector::random_shuffle and deque::random_shuffle. Then I might also want vector::increment_by_one and list::erase_every_second_item. Etc. Does it not seem that at some point you'd have to say no, because the required functionality is too specific and the user should implement it themselves. A class simply cannot cater for all conceivable needs.

So, what you can only argue about is that the C++ standard libraries say no too early.

Indeed, I must agree to some point. But I should also agree that if such is the case you should not lock it down. Instead, you should make it open to be derived so users can add more functionality if they require it.
But some things like to_lower, to_upper I really think they could have added for free.

But as to your ponder, I'd say add it as a member. Even if it means recompiling, it means you don't have to litter free functions everywhere in new headers everytime you want to change the interface or add new functionality.

Originally Posted by Elysia

Free functions:
- Good in sense that they are not limited to one object - they can work with multiple string classes, say, given they have the right interface.
- Increase encapsulation.
- More readable than algorithms.
- Bad in that this is the "the classes themselves does not do the work" analogy (I'll explain that later).

Member functions:
- The objects themselves perform the work.
- Most readable of all three.

And the "the class does all the work" or not... if you call a free function, then the function is doing the work. If you call a member function, the class does the work.

Algorithms are abstract since they detail a process, so I don't think that there are valid criticisms beyond what the algorithm does and how it performs. Any attempt to use an algorithm needs an implementation, where your opinions about methods and functions would be applicable. Despite what you may say there are "simpler" implementations of these aside from the choices made in C++, though far be it from me to assume your opinion.

I need to cite what you said to someone else to make a point:

Not nonsense. What the free function does is just take an extra argument and call the public interfaces. I could just as well create a member function that takes no extra arguments and uses public interfaces.
This completely eliminates the advantage of making it freestanding for this argument.
However, they are good for other things - especially not requiring to implement the same methods into all classes since a free function can work over multiple classes.

By your own admission, the only thing that a free function would do is call upon your interface, and there is no difference between that and the dot operator, essentially. You are making a syntactic argument, by preferring methods and presuming there is some pressing reason to hide the public interface. If your interface isn't helping the class "do its own work" in the sense that it could use itself, then it seems like your public methods have a design problem. The interface is how the object "does its own work."

We're going to have trouble buying your argument if it is only valid when you create a design problem in some object. If method complex() can only be used by method simple(), than simple() should be in the interface and not complex(). complex() is not a reason to avoid the rest of the program. Hide complex() within the recesses of the class, call it when you are supposed to through the interface. Presumably, this would allow safe free functions to be made, regardless of your opinion about whether a member function looks better.

Teamwork is important if you are going to write a program for anyone with the help of others.

Originally Posted by Elysia

Indeed, I must agree to some point. But I should also agree that if such is the case you should not lock it down. Instead, you should make it open to be derived so users can add more functionality if they require it.
But some things like to_lower, to_upper I really think they could have added for free.

But as to your ponder, I'd say add it as a member. Even if it means recompiling, it means you don't have to litter free functions everywhere in new headers everytime you want to change the interface or add new functionality.

I wouldn't mind to_upper and to_lower as part of the standard as well, but I really don't mind them as free functions (as in boost: they are just as simple to use but are more generic).

As to the second point. What if the new functionality was really specific and only needed by one file and not needed by 100 files? What if it was more than one (related but specific) function and I want to recompile the project often? So the choice is between separating the really specific things in a separate header or littering the class forever with things I might never need again?

That's a difficult one to answer. I'd like everything neatly into place, but... if it adds too much compile time I'd absolutely find another way of doing it.