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 Elysia Perhaps it is, but they should both do the same thing (if the algorithm is used ...

  1. #61
    The larch
    Join Date
    May 2006
    Posts
    3,573
    Quote Originally Posted by Elysia View Post
    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.
    Last edited by anon; 04-24-2008 at 09:46 AM.
    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).

  2. #62
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,543
    Quote Originally Posted by anon View Post
    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
    Last edited by Elysia; 04-24-2008 at 09:50 AM.
    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.

  3. #63
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,636
    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".
    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

  4. #64
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    Quote Originally Posted by laserlight View Post
    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.

  5. #65
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,543
    Quote Originally Posted by laserlight View Post
    Why are free functions worse than member functions?
    To your question, a quote:
    Quote Originally Posted by Elysia View Post
    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.
    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. #66
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,636
    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.
    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

  7. #67
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,543
    They've all been.
    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.

  8. #68
    The larch
    Join Date
    May 2006
    Posts
    3,573
    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.
    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).

  9. #69
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,636
    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 :|
    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

  10. #70
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,230
    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

  11. #71
    Registered User
    Join Date
    Apr 2008
    Posts
    890
    Quote Originally Posted by laserlight View Post
    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); ?

  12. #72
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Code:
    template <typename StringLike>
    StringLike to_upper(const StringLike &s);
    This one's less coupled.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  13. #73
    Registered User
    Join Date
    Apr 2008
    Posts
    890
    Quote Originally Posted by CornedBee View Post
    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?
    Last edited by medievalelks; 04-24-2008 at 11:05 AM.

  14. #74
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,230
    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

  15. #75
    The larch
    Join Date
    May 2006
    Posts
    3,573
    Quote Originally Posted by medievalelks View Post
    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.
    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).

Page 5 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