Boost logo

Boost :

From: Karl Nelson (kenelson_at_[hidden])
Date: 2000-08-19 18:18:04


>
> I'm probably missing something very silly, but this sub-thread has me
> totally confused. I'm not seeing the answer to Dave's question of having
> an overloaded function with one version modifying its argument (via T&)
> and another not (uses const T&). The response appears to be: to allow
> processing of objects that are not copyable. But I've probably skimmed a
> little too quickly and gotten sentences out of context. That can't be
> right:
[...]
> Could you clarify Karl?

If you want something to be an "exact" proxy that is whatever type
is passed in is passed directly to another function without changing
the arguments then the extreme specialization is needed.

Consider making a replacement for

 #define foo(a,b) real_func_foo(a,b)

to do this right such that if I place an int for and a A() for b
and to make it choose properly requires 4 templates.

template <class A,class B> foo(const A& a,const B&b) {real_func_foo(a,b);}

Will always chose real_func_foo(const A, const B) even if a or b is not
const. In other words C++ doesn't have a pass this with the most loginal
type, but instead you must chose one.

A classic example is I wish to replace "new" because I want something
called after new automatically.

  template <class O,class P1,class P2>
     O* create(const P1& p1,const P2& p2)
       { return manage(new O(p1,p2)); }

However, as soon as I encounted something defined like this...

  class A {
     ...
     A(string&, int);
  };

Using create<A>(s,1) failed. Result I ended up with 1024 templates
to do just that. (9 arguments.) It was so slow that it wasn't worth
it! Thus all my users have to type manage(new Gtk::Button("hello"))
if they want a managed widget.

You can just use "const T&" and accept that your arguments do
not select properly to the class they are. This may be acceptable
for the format command, but for a general proxy of functions C++
fails badly. (like my new function).

--Karl


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk