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 phantomotap (Assuming this "'string'" is provided by a third party...) If 'string' has some method of element ...

  1. #76
    Registered User
    Join Date
    Apr 2008
    Posts
    890
    Quote Originally Posted by phantomotap View Post
    (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.
    Coupling yourself to the implementation of string.


    I can't implement 'string::to_upper()' unless I inherit. (And then it would be 'my_string::to_upper()'.)
    Not if to_upper is virtual. Then you work through a base pointer or reference.

    I can distribute 'to_upper(string)', by itself, in any form.
    It won't work without string. It's completely dependent on it, in fact.

    The 'string::to_upper()' must be a part of the declaration of 'string' and probably must be packaged with the rest of the methods.
    to_upper(string) must as well. How can you build it without string?

  2. #77
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Quote Originally Posted by medievalelks View Post
    How would you implement that on a generic type?

    to_upper<Beeble>(myBeeble); // does what?
    Is Beeble string-like? Does it provide an iterator over code points and a +=(codepoint) operator? (That's one possible defintion of StringLike.)

    Code:
    concept StringLike<S>
    {
      requires DefaultConstructible<S>;
      requires Movable<S>;
    
      typename const_iterator;
      requires ForwardIterator<const_iterator>;
      requires SameType<const_iterator::value_type, codepoint_t>;
    
      const_iterator begin(S);
      const_iterator end(S);
    
      S &operator +=(S &, codepoint_t);
    }
    
    template <StringLike S>
    S to_upper(const S &s)
    {
      S out;
      for(StringLike<S>::const_iterator it = begin(s); it != end(s); ++it) {
        out += codepoint_to_upper(*it);
      }
      return out;
    }
    std::basic_string<codepoint_t> is just one possible implementation of this concept.
    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

  3. #78
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Quote Originally Posted by medievalelks View Post
    Coupling yourself to the implementation of string.
    No, only to its public interface.

    Not if to_upper is virtual. Then you work through a base pointer or reference.
    Only if it's there in string. Which it isn't, because string was written by a third party that didn't provide it.

    It won't work without string. It's completely dependent on it, in fact.
    Not the point. The point is that it can be distributed independently. Vendor A distributes string, vendor B distributes the "great additions to string" package containing to_uppper.



    to_upper(string) must as well. How can you build it without string?
    It only needs to reference the string package, not be part of it.
    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

  4. #79
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    22,166
    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

  5. #80
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,370
    ^_^

    Oh well, CornedBee and laserlight beat me to it.

    Soma

  6. #81
    Registered User
    Join Date
    Apr 2008
    Posts
    890
    Quote Originally Posted by CornedBee View Post
    No, only to its public interface.
    And if string changes, to_upper must change.

    Only if it's there in string. Which it isn't, because string was written by a third party that didn't provide it.
    Well, if you want to play those games. Yes, if to_upper isn't a member of string, you have to implement it on your own. Then we wouldn't be having this discussion in the first place, either.


    Not the point. The point is that it can be distributed independently. Vendor A distributes string, vendor B distributes the "great additions to string" package containing to_uppper.
    Which are worthless without string. I can write opengl programs and distribute them, but they won't work without opengl. That doesn't mean my programs aren't coupled to it.

    You're talking about packaging coupling, I'm talking about compile and run-time coupling.

  7. #82
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    22,166
    And if string changes, to_upper must change.
    That may or may not be true. As long as the public interface of string does not change, to_upper also does not need to change. If to_upper were a member function, then changes to the private implementation of string could adversely impact to_upper, so its implementation may need to change.

    Yes, if to_upper isn't a member of string, you have to implement it on your own.
    Yes. However, if the string class designer so wishes, to_upper could still be provided as a free function, possibly as an optional extension.
    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. #83
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,263
    Quote Originally Posted by medievalelks View Post
    And if string changes, to_upper must change.
    That is not generally the case. As long as string provides some basic access functionality through standard iterators, generic algorithms will work. A data abstraction which does not provide standard access methods (such as iterators) is worthless from a generic programming perspective, and I do not mourn the loss.

    There is a revolution occurring in C++ and a lot of you people are missing the boat.

  9. #84
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Quote Originally Posted by medievalelks View Post
    And if string changes, to_upper must change.
    If the public interface of a class changes, there are many issues you have. For that matter, since your member to_upper is part of the public interface, it might just go away in an interface change.
    But this is not a useful argument, because as a rule, the public interface of classes should not change, unless it's to be extended. In which case to_upper continues to work.

    Well, if you want to play those games. Yes, if to_upper isn't a member of string, you have to implement it on your own. Then we wouldn't be having this discussion in the first place, either.
    You've missed my point.
    The point is that the ability to implement to_upper myself even though it was not provided is proof that the free to_upper function is less coupled.

    Which are worthless without string. I can write opengl programs and distribute them, but they won't work without opengl. That doesn't mean my programs aren't coupled to it.

    You're talking about packaging coupling, I'm talking about compile and run-time coupling.
    And the original point you responded to was about packaging coupling, so it's you who's to blame for this discrepancy.
    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

  10. #85
    Registered User
    Join Date
    Apr 2008
    Posts
    890
    Quote Originally Posted by brewbuck View Post
    There is a revolution occurring in C++ and a lot of you people are missing the boat.
    Please. Spare me the latest Silver Bullet hype. Generic programming is just another tool in the toolbox.

  11. #86
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,263
    Quote Originally Posted by medievalelks View Post
    Please. Spare me the latest Silver Bullet hype. Generic programming is just another tool in the toolbox.
    I am not so naive to claim that any technology is a silver bullet. It's also not what I said.

  12. #87
    Registered User
    Join Date
    Apr 2008
    Posts
    890
    Quote Originally Posted by CornedBee View Post
    You've missed my point.
    The point is that the ability to implement to_upper myself even though it was not provided is proof that the free to_upper function is less coupled.
    Less coupled than what? The member function that doesn't exist?

  13. #88
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    22,166
    Even without generic programming (or the iterator pattern), the fact is that a member function or friend function may need to change if the class implementation changes, but a non-member non-friend function does not need to change in the face of internal changes to the class (or classes, as the case may be). This is what I had in mind when I mentioned that free functions imply loose coupling.

    EDIT:
    From the fourth article on my recommended list:
    Quote Originally Posted by Bjarne Stroustrup
    Another example would be a Date class, where the operations that actually change the day, month, and year have to be members. But the function that finds the next weekday, or the next Sunday, can be put on top of it. I have seen Date classes with 60 or 70 operations, because they built everything in. Things like find_next_Sunday. Functions like that don't logically belong in the class. If you build them in, they can touch the data. That means if you want to change the data layout, you have to review 60 functions, and make changes in 60 places.

    Instead, if you build a relatively simple interface to a Date class, you might have five or ten member functions that are there because they are logically necessary, or for performance reasons. It's hard for me to imagine a performance reason for a Date, but in general that's an important concern. Then you get these five or ten operations, and you can build the other 50 in a supporting library. That way of thinking is fairly well accepted these days. Even in Java, you have the containers and then the supporting library of static methods.
    (Emphasis mine.)
    Last edited by laserlight; 04-24-2008 at 12:52 PM.
    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. #89
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    22,918
    Wow, lots of replies. Have to make sure I go through the properly and see what I can dig out and reply to.
    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. #90
    Registered User
    Join Date
    Apr 2008
    Posts
    890
    Quote Originally Posted by laserlight View Post
    Even without generic programming (or the iterator pattern), the fact is that a member function or friend function may need to change if the class implementation changes, but a non-member non-friend function does not need to change in the face of internal changes to the class (or classes, as the case may be). This is what I had in mind when I mentioned that free functions imply loose coupling.

    EDIT:
    From the fourth article on my recommended list:

    (Emphasis mine.)
    I agree whole-heartedly with Bjarne that classes should not have as members functions that don't logically belong there. I was arguing in a more general sense, with the example of string and to_upper (which I never considered one way or the other as logically belonging).

    And I see your point about functions or classes that use a public interface not caring about internal changes as long as said public interface is preserved. We're just talking about different kinds of coupling.
    Last edited by medievalelks; 04-24-2008 at 01:02 PM.

Page 6 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, 05:37 AM
  2. Screwy Linker Error - VC2005
    By Tonto in forum C++ Programming
    Replies: 5
    Last Post: 06-19-2007, 03:39 PM
  3. error: template with C linkage
    By michaels-r in forum C++ Programming
    Replies: 3
    Last Post: 05-17-2006, 09:11 AM
  4. Class Template Trouble
    By pliang in forum C++ Programming
    Replies: 4
    Last Post: 04-21-2005, 05: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, 12:54 PM

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