Though implementation problem

This is a discussion on Though implementation problem within the C++ Programming forums, part of the General Programming Boards category; No, what I need is resize. Because if I try to to copy into a range which does not exist, ...

  1. #211
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,022
    No, what I need is resize. Because if I try to to copy into a range which does not exist, my iterators will throw an exception. No way around that.
    Therefore, resize, then copy.
    The biggest problem is that resize invalidates iterators, which is frustrating.
    Therefore I'm going ahead with the proxy project, to keep communications with iterators and base classes. Thereby I can notify the iterators when doing something that will invalidate them and fix them up.
    Code:
    // Oops! Will throw an exception if buffer is not big enough!
    typename StrType::const_iterator vCopyEnd = strSrc.const_begin() + (strSrc.const_end() - vTemp);
    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. #212
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,415
    BTW, the TYPE_FRIENDLY macro only seems to work for VS (at least I think it does - I get no compile error). But for GCC, it does not.
    Er... yes, it does, but it may not work for a particular version. (I just tested what I had posted with a few versions.) If it compiles, it works. It only changes the relationship of an object not how it is compiled.

    1): What version of GCC do you have? Where did you get it? (Please don't say "latest" or some other nonsense, with something like GCC even the least digit matters.)

    2): Do you actually have the 'typify' meta-function in scope? If you don't you need it in scope, or at least one like it. (Boost I think spells 'typify' as 'wrap'.)

    Because if I try to to copy into a range which does not exist, my iterators will throw an exception. No way around that.
    If your object provides the appropriate interface 'back_inserter(?)' will return an iterator that will extend the range. That is to say, if you have provided a STL interface, you need only call that function and it will generate a kind of proxy for you.

    Soma

    Code:
    template
    <
      typename type_F
    >
    class typify
    {
      public: typedef type_F type;
    };
    Last edited by phantomotap; 05-15-2008 at 03:09 PM.

  3. #213
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,022
    Ah, of course. I was not aware of how you had to do that.
    Now it compiles.
    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.

  4. #214
    The larch
    Join Date
    May 2006
    Posts
    3,573
    Is this all about creating a replace_all function? Or is the user going to use all your iterators to gain more power, for example, to replace all substrings "XXX" with a list of strings in a vector, one by one?

    One thing to consider is that while iterators are invalidated at resizing a string, indices aren't.
    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. #215
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,022
    For now, they are focused around the Replace function since it's the first one I have to get working, but after that, they will be used for a lot more.
    Find already uses the iterators, as well.

    And while indices are nice, they lack the power of iterators and the flexibility.
    I don't want any mix/match. I'm going all-out iterators, with the possibility of an implicit conversion indice -> iterator (integer constructor in iterators).
    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. #216
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,415
    Ah, of course. I was not aware of how you had to do that.
    Now it compiles.
    (I think you are talking to me.)

    To be honest, I have a tendency to assume '#include <anything_relevant>' when posting bits and bobs. There was no real reason for you to assume that the class wasn't part of the STL.

    Soma

  7. #217
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,022
    Perhaps not, but I still wouldn't be sure how the macro was intended to work.
    I haven't done much classes and put typedefs inside them while referring to those outside.

    Gah, another problem.
    First, let's inspect the new Proxy class:
    Code:
    #define Template template<typename Base, typename Iterator, typename Type>
    #define CStringExProxyTmpl CStringExProxy<Base, Iterator, Type>
    	
    Template class CStringExProxy
    It requires 3 template arguments: the base class and and the iterator between whom it shall delegate communication. And lastly also the type of data the classes are working with.
    Alright, so I should go ahead and create a friend for this class in the base class:

    Code:
    typedef Iterators::CIterator< T, CStringExProxy<CTmplStringBaseTmpl, T, Iterators::CIterator> > iterator;
    And right away we hit a problem!
    The iterator class must take the Proxy to be used as a template argument, so as we see, we get circular references! This is no go...

    So how about passing the types to be used to the iterator class instead of one big type?
    Code:
    #define CIteratorBaseTmpl CIteratorBase<VecT, Proxy, DerefType, Base>
    Template class CIteratorBase:
    	public boost::addable<CIteratorBaseTmpl, uint32_t>,
    	public boost::subtractable<CIteratorBaseTmpl, uint32_t>,
    	public std::iterator<std::random_access_iterator_tag, VecT>
    {
    public:
    	TYPE_FRIENDLY(Proxy<Base, VecT, CIteratorBaseTmpl>);
    Well, it would have worked fine, so long as the name of the class to be used as proxy wasn't passed!

    What's a good solution on this? Hard-code the class name? Or is there, yet again, some special syntax that allows me to append more template types to another template type?
    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. #218
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,415
    What's a good solution on this?
    A good solution is to simply use the proxy class as its own meta-function. The container class needs to store an instance of a proxy class. The iterator needs to store an instance of the proxy class. The proxy class must provide a special kind of interface to communicate between the two. This interface must be set at compile-time. The interface must be typed so that the result is type safe. The proxy must be able to be adjusted based on the instantiation of the container and iterator types. This, believe it or not is fairly simple.

    1): You provide a typed interface for the proxy by using a template class and you provide a default non-implementation of this class named 'template <?> proxy<void, ...>'. (That is: if the proxy class template requires four types the name of the base interface is 'template <> proxy<void, void, void, void>'.)

    2): You provide the proxy class a nested meta-function named 'apply' that takes the same number of parameters as the target proxy template. This goes for the real implementations and the non-implementation.

    3): In any reference to the iterator class you pass the non-implementation of the proxy class.

    4): Inside the iterator class you use the nested 'apply' meta-function to obtain the target type of the proxy you really want. (That is: with the above in mind, the type of the proxy you want would by something like 'typename proxy_T::template apply<char, my_string<char, my_iterator<char, proxy<>>>>::type'.)

    Now, you may think that this isn't type safe, but it is. The instances of the proxy template are unrelated by inheritance. Any instance of the iterator class will have to obtain a real proxy instance because the non-implementation isn't implemented. (To be honest, this is only a way to simplify certain code. The specialization isn't in any way needed.) Once you have the 'typedef' for this real instance you use that 'typedef' in every place you would have used the parameter that would have been passed directly to the template.

    Believe it or not, you lose nothing by doing it this way. You see, you setup the proxy class to forward the parameters to the nested 'apply' meta-function. Remember the actual container type, iterator type, and element type, are specified by indirection; any number of additional proxy specific parameters can be used. (Technically, this means partial specialization of the iterator on the types associated with the target proxy template is impossible. In reality this is nearly never relevant and can be mitigated simply and removed entirely by adding an additional layer of abstraction.)

    Or is there, yet again, some special syntax that allows me to append more template types to another template type?
    No special syntax, but you can code the support manually. Recursively nest the 'apply' meta-function as referenced above. (This isn't as difficult as you might think.) This alone doesn't solve the problem.

    Soma

  9. #219
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,022
    This, I think, is something I haven't done before so I'm not sure I can follow quite right. Examples would be appreciated. I typically find them to say a lot more than words.
    Thanks.

    EDIT:
    I just did some tests with nested templates and the following seems to work!

    Code:
    template<typename A, typename B, typename C> class CA {};
    template<typename A, template<typename A2, typename B2, typename C2> class B, typename C> class CB
    {
    	friend typename B<A, int, C>;
    };
    
    void Help()
    {
    	CB<int, CA, int> a;
    }
    Last edited by Elysia; 05-15-2008 at 05:59 PM.
    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.

  10. #220
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,415
    I just did some tests with nested templates and the following seems to work!
    That has problems of its own, but if you find it works for your scenario... go for it. (The problem is, the proxy class is the one that needs the friend listing. By using that sort of model your force any iterator or container classes to require a precise number of parameters. I suppose, with the right meta-function you might get around it...)

    Well, just in case:

    Code:
    template
    <
      typename container_F = void,
      typename iterator_F = void,
      typename element_F = void
    >
    class proxy_wh
    {
      template
      <
        typename container_FR = container_F,
        typename iterator_FR = iterator_F,
        typename element_FR = element_F
      >
      class apply
      {
        typedef proxy_wh<container_FR, iterator_FR, element_FR> type;
      };
    };
    
    template
    <
      typename container_F,
      typename element_F,
      typename proxy_F = proxy_wh<void, void, void>
    >
    class iterator_wh
    {
      typedef typename proxy_F::template apply<container_F, iterator_wh<container_F, element_F, proxy_F>, element_F> proxy_type;
      template
      <
        typename container_FR = container_F,
        typename element_FR = element_F,
        typename proxy_FR = proxy_F
      >
      class apply
      {
        typedef iterator_wh<container_FR, element_FR, proxy_FR> type;
      };
    };
    That should explain some of what I was discussing.

    Soma

  11. #221
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,022
    That sure is a tricky and complex code, though.
    Even coding with as many templates I have now, it gives a lot of nightmares.
    I think I'll stick to nested templates for the time being, at least. One little change destroys literally hundreds of lines of code.

    EDIT:
    GCC supports TR1, or doesn't it? std::tr1::shared_ptr won't work...
    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.

  12. #222
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    GCC does, but does your GCC? You need at least 4.2.
    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. #223
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,022
    Pain >_<
    All the include directories are missing from the compiler, so whatever I do, I get hundreds of errors.
    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.

  14. #224
    Banned
    Join Date
    May 2008
    Location
    Four Dots Planet
    Posts
    72
    since you seem to be already having problems with gcc tell me do you also have this problem now or before
    Quote Originally Posted by gcc
    error: expected unqualified-id before '=' token
    why gcc would expect unqualified-id and what is that id

  15. #225
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,022
    That typically just means that GCC encountered something it didn't like or was expecting.
    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.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. WS_POPUP, continuation of old problem
    By blurrymadness in forum Windows Programming
    Replies: 1
    Last Post: 04-20-2007, 07:54 PM
  2. Laptop Problem
    By Boomba in forum Tech Board
    Replies: 1
    Last Post: 03-07-2006, 06:24 PM
  3. implementation file
    By bejiz in forum C++ Programming
    Replies: 5
    Last Post: 11-28-2005, 01:59 AM
  4. Replies: 5
    Last Post: 11-07-2005, 11:34 PM
  5. Memory Problem - I think...
    By Unregistered in forum C Programming
    Replies: 4
    Last Post: 10-24-2001, 01:14 PM

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