Re: template problems

[Thomas Maier <T dot Maier at epost dot de>]

Thanks a lot for your quick and detailed answer.  However I guess I
couldn't make things clear.

On Fri, 2002-07-26 at 20:11, Gokhan Kisacikoglu wrote:
> I am not sure you can pass address of template functions, especially
> when these functions are relative to a certain instance (not static), I
> don't know how it would all work. Is this described in the ISO spec? I
> am not sure... Maybe somebody can tell us more...

Well, when I say

template<class Container> bla(some_arg) {...}

with "some_arg"'s type being dependant by Container (e.g.
Container::mapped_type) and call bla with 
map<size_t,string> for Container
then some_arg would be of type Container::mapped_type, i.e. string.  Is
there any reason the compiler cannot know this?  Well, the question
should probably be "Is this a special instance of more general problem
(joke intended) so the compiler cannot know in general?".  At least in
this case, string looks pretty concrete to me and nothing prevents me
from taking string's size() method's address in a non-template function
(see the example in my last mail, function f()).  Why can't I do that in
a template function?  I thought the problem is that I can only attribute
the first type with typename in a "deeper-than-one-level-scope".  But
maybe the actual problem is a different one.  To say it again: for
some_arg I can't say 

some_return_type (Container::mapped_type::* some_arg)()

and I thought it is only because I do not know where and how to place
typename keywords.  Only thing I can guess here is that the compiler
somehow does not have enough type information (you even have to tell it
that Container is a typename).  I checked it with a
"just-one-level-scope"

some_return_type (SomeTemplateType::* some_arg)()

This works, so I could move the information on which method to call to
get the value's keys to the fill method, see below.



> 
> > wanted to write an assoc_insert_iterator to insert a value into a map
> > like a back_inserter (gives a back_insert_iterator that) inserts into a
> > list, for example.  The iterator needs to be parameterized with some X
> 
> You can already do this, if you have your value_types (pair of key and
> data) stored in an array let's say, that you want to insert them into a
> map by using the insert_iterator, you could easily type the following;
> 
> #include <map>
> #include <vector>
> #include <iterator>
> #include <string>
> #include <iostream>
> 
> using namespace std; 	// for simplicity
> 
> // a simple mapping
> //
> typedef pair <int, string> int_string_pair;
> 
> typedef map <int_string_pair :: first_type, 
> 	    int_string_pair :: second_type> mapped_strings;
> 
> // a simple array (let's say)
> //	
> typedef vector <int_string_pair> map_value_array;
> 
> int main(void)
> {
>     // instances
>     //
>     
>     // value in an arrays
>     //	
>     map_value_array array;
>     
>     array.reserve(3);
>     array.push_back( make_pair( 1, "one" ) );
>     array.push_back( make_pair( 3, "three" ) );	// randomly ordered
>     array.push_back( make_pair( 2, "two" ) );
>     
>     // insert into a map instance
>     //	
>     mapped_strings mstrs;
>     
>     copy( array.begin(), array.end(), 
> 	insert_iterator <mapped_strings> (mstrs, mstrs.end()) );
>     
>     mapped_strings :: iterator iter = mstrs.begin();
>     cerr << iter->first << " " << iter->second << endl; ++ iter;
>     cerr << iter->first << " " << iter->second << endl; ++ iter;
>     cerr << iter->first << " " << iter->second << endl; ++ iter;
>     
>     assert( iter == mstrs.end() );
>     
>     return 0;
> }


Well, I wanted to write a function fill() that is able to fill a
container no matter if it is a sequence or some associative thingy.  I
do not have key-value-pairs.  I only have values, say of type Value. 
When I want to insert them into a list<Value> or vector<Value>, it's
easy, I use back_inserter() to get a back_insert_iterator.  But when I
want to insert them into a map<Key, Value>, I'd like to automatically
let the fill function get the keys via some method

Key Value::key_method()

if is there and if not, via a global non-member function

Key key_function(Value)


I can of course move the information which method (or function) to call
into the fill() function which works there, as the scope is only one
"::" because I parameterize fill with the value type Value and don't
need to get Value via Container::mapped_type.  So I end up with

typename Container::key_type (Value::*key_method)()

instead of

typename Container::key_type (Container::mapped_tpe::*key_method)()

which works.  But ad hoc I consider that solution less elegant and
general than having an assoc_insert_operator and thus having no need to
give fill() anything but such an iterator.  Maybe you have a different
opinion on this, feel free to tell me.

Hm, I'm just thinking that I wouldn't probably want to parameterize
fill() with Value because I already parameterize it either with
Container or with OutIter and I should be able to get Value type from
both of these.  Parameterizing assoc_insert_iterator or fill() with a
(very general) Operation type (like the standard functors do) and using
mem_fun and prt_fun stuff works, too.  But that seems overly general and
I'd like to restrict the types when I know something about them.  Damn,
I fiddled around to much with that.  I think I need to carefully rethink
what should be parameterized with how many and which types.  We're gonna
move during the next couple of days so I won't respond to any mail.  At
least I can think about this when I'm carrying boxes up to our new
apartment :).

> 
> check out:
> 
> http://www.sgi.com/tech/stl/insert_iterator.html
> 
> The second parameter is the hint to tell where to start the search for
> the appropriate insertion location in the case of map, it would be the
> exact insertion point in the case of list for example...
> 
> HTH,
> Gokhan

Yes, I know this one.  But thanks a lot anyway, have a good night, at
least now and here in Germany :), Thomas.

-- 
Thomas Maier <T.Maier@tu-bs.de>