Thread: Design doubt

  1. #1
    Registered User
    Join Date
    Nov 2008
    Posts
    75

    Design doubt

    I'm creating a little container class, but I have a design doubt. I'll post here some example code:

    Code:
    template<T> class useful_class {
    public:
    
        void some_func()
        {
            node *node_;
            ...
        }
        ...
    
        class iterator {};
    
        class const_iterator {};
    
    private:
        struct node {};
        ...
    };
    I had then to use a variable of type node inside a function of iterator and const_iterator, so I changed my class like this(friend doesn't seem to work for types, right? only for variables when the type is already known):
    Code:
    template<T> class useful_class {
    public:
    
        struct node {};
    
        void some_func()
        {
            node *node_;
            ...
        }
        ...
    
        class iterator {
        public:
    
            iterator &operator++()
            {
                node *node_;
                ...
            }
        };
    
        class const_iterator {
        public:
    
            const_iterator &operator++()
            {
                node *node_;
                ...
            }
        };
    
    private:
        ...
    };
    Not really elegant, but not really a big problem either.Anyway, is it solvable in any other(better) way?

  2. #2
    Registered User
    Join Date
    Nov 2008
    Posts
    75
    I thought about doing this:

    Code:
    template<K> iterator_t{}
    
    typedef iterator_t<node> iterator;
    But it doesn't seem to work either, because the type isn't declared in the same context, so there's still the same problem.
    Last edited by MisterIO; 10-17-2009 at 12:39 PM.

  3. #3
    The larch
    Join Date
    May 2006
    Posts
    3,573
    I think you'll find it is not uncommon not to nest those classes, and indeed containers often typedef some separate iterator class.

    Also, friend does work for classes (except it might not be all that simple for template classes).
    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).

  4. #4
    Registered User
    Join Date
    Nov 2008
    Posts
    75
    Quote Originally Posted by anon View Post
    I think you'll find it is not uncommon not to nest those classes, and indeed containers often typedef some separate iterator class.

    Also, friend does work for classes (except it might not be all that simple for template classes).
    About the first statement: could you clarify? What would that change for my problem? I'd still have to make node public, wouldn't I?

    About the second statement: frankly, from the messages i get from g++, it seems to me that he's angry because I didn't declare node in the same context(In the case I make it private and use friend), while instead it never complains when I access private members from friend classes where the type of the member is already known to the friend class. Yet it could simply be that the brain damage due to reading g++ errors on template classes made me unable to understand what's the real problem.
    Last edited by MisterIO; 10-17-2009 at 12:50 PM.

  5. #5
    The larch
    Join Date
    May 2006
    Posts
    3,573
    About the first statement: could you clarify? What would that change for my problem? I'd still have to make node public, wouldn't I?
    For example, if you look at GCC implementation of list, you might find that the node struct(!) is only "hidden" within a nested namespace. There is no reason to go out of your way to hide it from the user: the container never exposes any nodes to the user, and even though you could create a node instance of your own, it wouldn't have much use for you. Just make it so it doesn't get in the way.

    As for the second question, it might be hard to tell without any real code and compiler message.
    Last edited by anon; 10-17-2009 at 02:35 PM.
    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).

  6. #6
    Registered User
    Join Date
    Nov 2008
    Posts
    75
    Quote Originally Posted by anon View Post
    For example, if you look at GCC implementation of list, you might find that the node struct(!) is only "hidden" within a nested namespace. There is no reason to go out of your way to hide it from the user: the container never exposes any nodes to the user, and even though you could create a node instance of your own, it wouldn't have much use for you. Just make it so it doesn't get in the way.

    As for the second question, it might be hard to tell without any real code and compiler message.
    Yes, I had to make node public but there's no public function that returns nodes(nor there's obviously any public variable), so having node public doesn't create any problem for the internal workings of the class. My only problem was just about the style. I hate c++(well, part of it. I like template classes. After all, they're just type-checked macros)(while instead I love C, my preferred language), but if I have to use it, I prefer to use its characteristics to have a clean design. That said, if even the gnu stdc++ library, as you said, does something like that, then I won't even try to go any further than this.

    Thanks a lot for the help!
    Last edited by MisterIO; 10-17-2009 at 03:37 PM.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. which design is better to wrap another class instance
    By George2 in forum C++ Programming
    Replies: 7
    Last Post: 04-13-2008, 12:27 AM
  2. any comments about a cache design?
    By George2 in forum C Programming
    Replies: 6
    Last Post: 09-14-2006, 12:53 PM
  3. Implementing Inheritence into your design
    By bobthebullet990 in forum C++ Programming
    Replies: 6
    Last Post: 08-05-2006, 04:40 PM
  4. Opinions on new site design
    By jverkoey in forum A Brief History of Cprogramming.com
    Replies: 23
    Last Post: 01-21-2005, 01:34 PM

Tags for this Thread