Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #11051 > unrolled thread

Limiting function input only to __int64 but not int...

Back to article view | Back to comp.lang.c++

Contents

  Limiting function input only to __int64 but not int... "A" <a@a.a> - 2011-10-24 00:28 +0200
    Re: Limiting function input only to __int64 but not int... Ian Collins <ian-news@hotmail.com> - 2011-10-24 11:49 +1300
      Re: Limiting function input only to __int64 but not int... Juha Nieminen <nospam@thanks.invalid> - 2011-10-24 08:08 +0000
        Re: Limiting function input only to __int64 but not int... yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-10-24 14:24 +0000
    Re: Limiting function input only to __int64 but not int... Marc <marc.glisse@gmail.com> - 2011-10-23 22:52 +0000
      Re: Limiting function input only to __int64 but not int... "A" <a@a.a> - 2011-10-24 01:32 +0200
    Re: Limiting function input only to __int64 but not int... Goran <goran.pusic@gmail.com> - 2011-10-23 23:29 -0700
      Re: Limiting function input only to __int64 but not int... "A" <a@a.a> - 2011-10-24 17:11 +0200
        Re: Limiting function input only to __int64 but not int... Robert Wessel <robertwessel2@yahoo.com> - 2011-10-24 12:17 -0500
          Re: Limiting function input only to __int64 but not int... Richard Damon <news.x.richarddamon@xoxy.net> - 2011-10-24 13:49 -0400
          Re: Limiting function input only to __int64 but not int... "A" <a@a.a> - 2011-10-25 00:12 +0200
            Re: Limiting function input only to __int64 but not int... Richard Damon <news.x.richarddamon@xoxy.net> - 2011-10-24 20:20 -0400
            Re: Limiting function input only to __int64 but not int... Christian Gollwitzer <auriocus@gmx.de> - 2011-10-25 07:27 +0200
              Re: Limiting function input only to __int64 but not int... Arne Mertz <arnemertz@googlemail.com> - 2011-10-26 01:02 -0700
    Re: Limiting function input only to __int64 but not int... Marcel Müller <news.5.maazl@spamgourmet.com> - 2011-10-24 09:18 +0200
      Re: Limiting function input only to __int64 but not int... Ian Collins <ian-news@hotmail.com> - 2011-10-24 20:53 +1300
        Re: Limiting function input only to __int64 but not int... Ian Collins <ian-news@hotmail.com> - 2011-10-24 20:58 +1300

#11051 — Limiting function input only to __int64 but not int...

Is there a way (except overloading) to limit function input to accept 
__int64 but to get a compiler (preferable) or runtime (less preferable) 
error if it is called with int?

for example:

void myfunction(__int64 param)    // Accepts only __int64 as input and no 
smaller
{
}

myfunction((__int64)1);    // Call OK
myfunction((int)1);        // Call fails or better - compiler reports error

[toc] | [next] | [standalone]

#11052

On 10/24/11 11:28 AM, A wrote:
> Is there a way (except overloading) to limit function input to accept
> __int64 but to get a compiler (preferable) or runtime (less preferable)
> error if it is called with int?
>
> for example:
>
> void myfunction(__int64 param)    // Accepts only __int64 as input and no
> smaller
> {
> }
>
> myfunction((__int64)1);    // Call OK
> myfunction((int)1);        // Call fails or better - compiler reports error

You can use a function template to force a link error:

#include <stdint.h>

template <typename T> void f( T n );

template <> void f( int64_t n ) // Specialise for acceptable types
{
}

Or give the function template a body to force a compiler warning:

template <typename T> void f( T n )
{
   T tmp = n/0;
}

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#11060

Ian Collins <ian-news@hotmail.com> wrote:
> Or give the function template a body to force a compiler warning:
> 
> template <typename T> void f( T n )
> {
>   T tmp = n/0;
> }

  I don't think that's a very good idea.

[toc] | [prev] | [next] | [standalone]

#11064

In article <4ea51cef$0$2800$7b1e8fa0@news.nbl.fi>,
Juha Nieminen  <nospam@thanks.invalid> wrote:
>Ian Collins <ian-news@hotmail.com> wrote:
>> Or give the function template a body to force a compiler warning:
>> 
>> template <typename T> void f( T n )
>> {
>>   T tmp = n/0;
>> }
>
>  I don't think that's a very good idea.

A compile time assertion would be a bit safer.

[toc] | [prev] | [next] | [standalone]

#11053

"A"  wrote:

> Is there a way (except overloading) to limit function input to accept 
> __int64 but to get a compiler (preferable) or runtime (less preferable) 
> error if it is called with int?

Assuming that __int64 is not the same type as int.

with overloading (what's wrong with overloading?):
void f(long){}
void f(int)=delete;

with sfinae:
template<class T,class=typename std::enable_if<std::is_same<T,long>::value>::type> void f(T){}

[toc] | [prev] | [next] | [standalone]

#11054

Thank you for your answers so far. I was hoping though for something without 
templates. I did found though BOOST_STRONG_TYPEDEF which pretty much does 
this. 

[toc] | [prev] | [next] | [standalone]

#11056

On Oct 24, 12:28 am, "A" <a...@a.a> wrote:
> Is there a way (except overloading) to limit function input to accept
> __int64 but to get a compiler (preferable) or runtime (less preferable)
> error if it is called with int?

Out of curiosity... Why? int "is an" __int64 any way you look at this.
Why would it matter?

Goran.

[toc] | [prev] | [next] | [standalone]

#11065

"Goran" <goran.pusic@gmail.com> wrote in message 
news:c59f1d33-57bf-47f9-b23a-90cfff62c8c3@f36g2000vbm.googlegroups.com...
>Out of curiosity... Why? int "is an" __int64 any way you look at this.
>Why would it matter?

because function requires explicitly __int64 because ID's are 64-bit, 
providing 32-bit int would ruin ID's that go over the 32-bit boundary. This 
may happen when I do text-to-int conversions using StrToInt and forget to 
put StrToInt64 instead.

In Borlangearcadero C++ Builder 2010 which I use, these functions output int 
and __int64 so compiler SHOULD be able to check these but unfortunately it 
doesn't - even if I enable W8102 Implicit conversion of '%s' to '%s' (C++) 
but it doesn't do what it is supposed to. I tried casting to wrong type but 
the warning is still not triggered. 

[toc] | [prev] | [next] | [standalone]

#11066

On Mon, 24 Oct 2011 17:11:48 +0200, "A" <a@a.a> wrote:

>
>"Goran" <goran.pusic@gmail.com> wrote in message 
>news:c59f1d33-57bf-47f9-b23a-90cfff62c8c3@f36g2000vbm.googlegroups.com...
>>Out of curiosity... Why? int "is an" __int64 any way you look at this.
>>Why would it matter?
>
>because function requires explicitly __int64 because ID's are 64-bit, 
>providing 32-bit int would ruin ID's that go over the 32-bit boundary. This 
>may happen when I do text-to-int conversions using StrToInt and forget to 
>put StrToInt64 instead.
>
>In Borlangearcadero C++ Builder 2010 which I use, these functions output int 
>and __int64 so compiler SHOULD be able to check these but unfortunately it 
>doesn't - even if I enable W8102 Implicit conversion of '%s' to '%s' (C++) 
>but it doesn't do what it is supposed to. I tried casting to wrong type but 
>the warning is still not triggered. 


Why not use the usual trick of imbedding the handle in a structure?

struct MyHandle(__int64 h;};

And use a MyHandle as the parameter or return value?

Alternatively, explicitly declare forms for those functions using int,
short, etc., and then never define them - that way the link will fail.
Better yet, if your compiler supports the new standard, use the
"=delete" form:

void f(__int64);  //supply actual definition
void f(int)=delete; //can't be called

Of course that's ugly because of the number of definitions you need to
supply to cover all of the usual conversions.

[toc] | [prev] | [next] | [standalone]

#11067

On 10/24/11 1:17 PM, Robert Wessel wrote:
> On Mon, 24 Oct 2011 17:11:48 +0200, "A"<a@a.a>  wrote:
>
>>
>> "Goran"<goran.pusic@gmail.com>  wrote in message
>> news:c59f1d33-57bf-47f9-b23a-90cfff62c8c3@f36g2000vbm.googlegroups.com...
>>> Out of curiosity... Why? int "is an" __int64 any way you look at this.
>>> Why would it matter?
>>
>> because function requires explicitly __int64 because ID's are 64-bit,
>> providing 32-bit int would ruin ID's that go over the 32-bit boundary. This
>> may happen when I do text-to-int conversions using StrToInt and forget to
>> put StrToInt64 instead.
>>
>> In Borlangearcadero C++ Builder 2010 which I use, these functions output int
>> and __int64 so compiler SHOULD be able to check these but unfortunately it
>> doesn't - even if I enable W8102 Implicit conversion of '%s' to '%s' (C++)
>> but it doesn't do what it is supposed to. I tried casting to wrong type but
>> the warning is still not triggered.
>
>
> Why not use the usual trick of imbedding the handle in a structure?
>
> struct MyHandle(__int64 h;};
>
> And use a MyHandle as the parameter or return value?
>
> Alternatively, explicitly declare forms for those functions using int,
> short, etc., and then never define them - that way the link will fail.
> Better yet, if your compiler supports the new standard, use the
> "=delete" form:
>
> void f(__int64);  //supply actual definition
> void f(int)=delete; //can't be called
>
> Of course that's ugly because of the number of definitions you need to
> supply to cover all of the usual conversions.

Actually, once you define one disallowed form, the rest become 
ambiguous. For example, calling with a "short" neither short->int or 
short->__int64 has a preference, so I believe it should give an error. I 
don't think the =delete removes that version from overload resolution, 
but I haven't looked at it in detail yet.

[toc] | [prev] | [next] | [standalone]

#11069

"Robert Wessel" <robertwessel2@yahoo.com> wrote in message 
news:is6ba7hjetjr8g1iaj947qjkfmuu6a27lc@4ax.com...
> void f(__int64);  //supply actual definition
> void f(int)=delete; //can't be called

I actually like this solution but the compiler doesn't support it. I guess 
I'll be looking for alternate solutions. 

[toc] | [prev] | [next] | [standalone]

#11070

On 10/24/11 6:12 PM, A wrote:
> "Robert Wessel"<robertwessel2@yahoo.com>  wrote in message
> news:is6ba7hjetjr8g1iaj947qjkfmuu6a27lc@4ax.com...
>> void f(__int64);  //supply actual definition
>> void f(int)=delete; //can't be called
>
> I actually like this solution but the compiler doesn't support it. I guess
> I'll be looking for alternate solutions.
>
>

if it doesn't support the =delete syntax, declaring (but not defining) 
void f(unsigned char); (choose an integer type that you are actually 
unlikely to mistakenly use) will make a call of f(1) ambiguous and thus 
an error. You want to make the undefined type an unlikely mistake as if 
you use it by mistake, you are just going to get a link error, and you 
will have to search to find where it is actually called.

[toc] | [prev] | [next] | [standalone]

#11072

Am 25.10.11 00:12, schrieb A:
> "Robert Wessel"<robertwessel2@yahoo.com>  wrote in message
> news:is6ba7hjetjr8g1iaj947qjkfmuu6a27lc@4ax.com...
>> void f(__int64);  //supply actual definition
>> void f(int)=delete; //can't be called
>
> I actually like this solution but the compiler doesn't support it. I guess
> I'll be looking for alternate solutions.
>

Maybe it supports #pragma error?
Then you can write

void f(__int64);  //supply actual definition
void f(int) {
#pragma error "f must be called with an __int64"
}

Or you could forward-declare it
void f(int);
without an actual implementation; this would give a link error.

	Christian

[toc] | [prev] | [next] | [standalone]

#11089

On Oct 25, 7:27 am, Christian Gollwitzer <aurio...@gmx.de> wrote:
> Maybe it supports #pragma error?
> Then you can write

#pragma error is not very portable, e.g. MSVC does not
sopport it, instead, it issues a warning about the
unsupported pragma and happily continues compiling,
i.e. f(int) may be called.

overloading f(int) and f(__int64) imo is not a good idea,
because once you port the whole thing to a 64 bit machine
int and __int64 become the same and you get either a
redefinition error (if you actually defined f(int)), or
the whole "error detection via link error or ambiguity"
magically dissapears if you only declared f(int), as it
is just another declaration of f(__int64).
In your case the latter behavior may be ok, if the
problem is only about disambiguating 32 bit int and __in64
in 32 bit systems. But maybe StrToInt outputs __int32
even on 64 bit systems or something similar happens so you
want to keep up the 32 bit integer detection even on 64 bit
systems.

To make things short(er), I would use overloading, but not
with any specific integer type but with a template:
given f(__int64) as the function to be called only for
64bit types, you have several variants

Variant a)
template <typename T>
void f(T) = delete; //overload resolution calls this for
any T that is not the same as __int64

Variant b), C++0x without deleted functions
template <typename T>
void f(T)
{ static_assert(false, "call f only with __int64!"); }

Variant c), C++0x, less restrictive
#include <type_traits>
template <typename T>
f(T t) -> decltype(f(__int64))
{
  // assert T is "sufficiently close to" __int64
  static_assert(std::is_integral<T>::value
    && std::is_convertible<T, __int64>::value
    && sizeof(T) >= sizeof(__int64));

  return f(__int64(t));
}

If your compiler lacks support for static_assert, you
could use either std::enable_if or the STATIC_ASSERT
macro from the loki library. If your standard library
has no <type_traits>, boost provides similar utilities.

HTH Arne

[toc] | [prev] | [next] | [standalone]

#11057

On 24.10.2011 00:28, A wrote:
> Is there a way (except overloading) to limit function input to accept
> __int64 but to get a compiler (preferable) or runtime (less preferable)
> error if it is called with int?

> for example:
>
> void myfunction(__int64 param)    // Accepts only __int64 as input and no
> smaller
void myfunction(const __int64& param);


Marcel

[toc] | [prev] | [next] | [standalone]

#11058

On 10/24/11 08:18 PM, Marcel Müller wrote:
> On 24.10.2011 00:28, A wrote:
>> Is there a way (except overloading) to limit function input to accept
>> __int64 but to get a compiler (preferable) or runtime (less preferable)
>> error if it is called with int?
>
>> for example:
>>
>> void myfunction(__int64 param)    // Accepts only __int64 as input and no
>> smaller
> void myfunction(const __int64&  param);

Won't the normal promotion rules still apply?

   myfunction( 2 );

Compiles happily as does

   int n = 0;
   myfunction( n );

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#11059

On 10/24/11 08:53 PM, Ian Collins wrote:
> On 10/24/11 08:18 PM, Marcel Müller wrote:
>> On 24.10.2011 00:28, A wrote:
>>> Is there a way (except overloading) to limit function input to accept
>>> __int64 but to get a compiler (preferable) or runtime (less preferable)
>>> error if it is called with int?
>>
>>> for example:
>>>
>>> void myfunction(__int64 param)    // Accepts only __int64 as input and no
>>> smaller
>> void myfunction(const __int64&   param);
>
> Won't the normal promotion rules still apply?
>
>     myfunction( 2 );
>
> Compiles happily as does
>
>     int n = 0;
>     myfunction( n );

Hit send too soon, I was going to add that

void myfunction( int64_t& param );

was probably what you intended to type.

-- 
Ian Collins

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web