In article <...>, martelli@cadlab.cadlab.it (Alex Martelli) wrote:

> template <class T> inline bool can_memmove(const T&) { return false; }
> inline bool can_memmove(const int&) { return true; } // etc

Perhaps this would be better as something like the following:

template<class T> class type_traits {
    enum { can_memmove = true };
};

class type_traits<foo> {
    enum { can_memmove = false };
};

etc.

That way you get the answer to can_memmove at compile time. Not only
does this save you code (both time and space) but it allows you to
do things which require compile-time constants, such as using
type_traits<T>::can_memmove as a parameter to some other template.

--
--
Scott Howlett
Storm Software, Inc.
howlett@netcom.com
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

howlett@netcom.com (Scott Howlett) writes:
 ...
>> template <class T> inline bool can_memmove(const T&) { return false; }
>> inline bool can_memmove(const int&) { return true; } // etc

>Perhaps this would be better as something like the following:

>template<class T> class type_traits {
>    enum { can_memmove = true };
>};

>class type_traits<foo> {
>    enum { can_memmove = false };
>};

>That way you get the answer to can_memmove at compile time. Not only
>does this save you code (both time and space) but it allows you to

I would be surprised to find myself using a compiler unable to
optimize away an inline function call returning a manifest constant...
it is however true that the idiom you propose seems to have no
offseting defect.

>do things which require compile-time constants, such as using
>type_traits<T>::can_memmove as a parameter to some other template.

Conceded, and this makes the idiom you suggest appear to be quite
preferable, thanks.


Alex
--
DISCLAIMER: these are TOTALLY personal opinions and viewpoints, NOT connected
in any way with my employer, nor any other organization or individual!
Email: martelli@cadlab.it                            Phone: +39 (51) 597313
CAD.LAB s.p.a., v. Ronzani 7/29, Casalecchio, Italia   Fax: +39 (51) 597120
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

clamage@Eng.sun.com (Steve Clamage) wrote:

>In article 100000@gusak, "Brett W. Denner" <dennerbw@cliffy.lfwc.lockheed.com>
 writes:
>>Is there a way to identify whether a data type in a template function is a
>>class or a built-in type?  For example,
>>
>>template <class T> void
>>func(T var)
>>{
>>    if ( /* test whether T is a built-in type */ )
>>  /* do something based on T being a built-in type */;
>>    else
>>        /* do something else based on T being a user-define type */;A
>>}
>>
>>Will rtti allow me to test for this?  Is there another way of determing this?


>What is the actual problem you are trying to solve? Is it really the case
>that if T is a double or a char* or a FILE* you will do operation A, but if
>it is a complex or a string or an fstream you will do operation B?

I did have this problem when trying to write a decent array template.
For numeric and pointer types, I'd like to use memmove when the array
grows and is relocated. For class types that cannot be done in
general. I did "solve" the problem by having two templates, but now
the risk is that someone who doesn't understand the distinction uses
the "BuiltinTypeArray" (not its real name) with a class type, which
might have bizarre results. So I think Brett's desire is not totally
outlandish.

Cay
horstman@cs.sjsu.edu
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

>>>>> "AM" == Alex Martelli <martelli@cadlab.cadlab.it> writes:
[...]
>> Such a rule is in the DWP (let me know if your compiler supports it,
>> mine doesn't :-). BTW, this is called partial specialization...

AM> Ah -- wonderful!  I had missed this novelty... chapter and verse of
AM> the DWP please...?  No, g++ 2.7.0, the compiler I use, does not
AM> support it yet (I did try as soon as I read this...:-).
[...]

DWP (14.6 [temp.class.spec]), many verses apply; verse 2 shows an
example of what you (and I :) want.

Until recently I was under the impression that partial specialization
is not as general as one may imagine; in particular, I thought:

 template<typename T> struct S { ... };
 template<typename T> struct X { ... };
 template<typename T> struct S<X<T> > { ... }; // Error

was illegal according to the DWP. However, someone very knowledgeable
in this area told me it _is_ legal C++ now. Just FYI.

BTW, I was sort of joking when asking if your compiler supports it:
I'm pretty sure no compiler I could have access to allows partial
specialization.

 Daveed

---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]