How properly inherit from template?

This is a discussion on How properly inherit from template? within the C++ Programming forums, part of the General Programming Boards category; Originally Posted by anon Ouch. I though the algorithms library was the most OOP part of standard libraries - container ...

  1. #46
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,791
    Quote Originally Posted by anon View Post
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  2. #47
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,941
    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.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  3. #48
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    [edit]>>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!".[/edit]

    In a way, I would say your analogy is somewhat reversed. Its more like a carpenter with a tool box wherein, he relies on skill and experience to know what tool to use when compared to a magician who just pulls the right thing out of his hat at the right moment. Sometimes its helpful to have a magic solution that seems to work based on unknown principles, while other times nothing beats using the right tool for the job.

  4. #49
    The larch
    Join Date
    May 2006
    Posts
    3,573
    Quote Originally Posted by Elysia View Post
    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?
    I might be wrong.

    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
    Quoted more than 1000 times (I hope).

  5. #50
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,791
    Quote Originally Posted by anon View Post
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  6. #51
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,339
    I prefer to do it myself.
    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?

    The string itself should make itself lower.
    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.

    It knows best itself how to do it anyway.
    Define "best"! Even with whatever definition, it would know "best" only if it is programmed with that knowledge.

    I don't like utility functions that do it an indirect way.
    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?

    Soma

  7. #52
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,941
    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).
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  8. #53
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,791
    Quote Originally Posted by phantomotap View Post
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  9. #54
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    [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.
    Last edited by master5001; 04-24-2008 at 08:51 AM.

  10. #55
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,791
    Quote Originally Posted by laserlight View Post
    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.

    Quote Originally Posted by master5001 View Post
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  11. #56
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,941
    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.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  12. #57
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,791
    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).
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  13. #58
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,941
    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"?
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  14. #59
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,791
    Quote Originally Posted by laserlight View Post
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  15. #60
    Registered User
    Join Date
    Apr 2008
    Posts
    890
    Quote Originally Posted by Elysia View Post
    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.
    I think you'd be happier with Java, where everything is an object whether it makes sense or not.

Page 4 of 8 FirstFirst 12345678 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Specialising a member function with a template template parameter
    By the4thamigo_uk in forum C++ Programming
    Replies: 10
    Last Post: 10-12-2007, 04:37 AM
  2. Screwy Linker Error - VC2005
    By Tonto in forum C++ Programming
    Replies: 5
    Last Post: 06-19-2007, 02:39 PM
  3. error: template with C linkage
    By michaels-r in forum C++ Programming
    Replies: 3
    Last Post: 05-17-2006, 08:11 AM
  4. Class Template Trouble
    By pliang in forum C++ Programming
    Replies: 4
    Last Post: 04-21-2005, 04:15 AM
  5. oh me oh my hash maps up the wazoo
    By DarkDays in forum C++ Programming
    Replies: 5
    Last Post: 11-30-2001, 11:54 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21