Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Argument type of function and safe types and types, arguments canhandle safely

Reply
Thread Tools

Argument type of function and safe types and types, arguments canhandle safely

 
 
ittium
Guest
Posts: n/a
 
      12-08-2011
Groups,
I have few doubts regarding argument type of function and types,
arguments can handle safely. I know these issues have been discussed at
multiple places on internet. I wanted to see the big picture and needed
opinion of C++ gurus

When you pass by value - Copy constructor is called (except for basic
data type like int, float). you can pass the **same type variable** only

When you pass by reference - A reference will be intialized with pass
value. you can pass **non-const same type or derived type** (passing a
constant type will return in error)

When you pass by constant reference you can pass **const/non-const of
same type or derived type**.

When you pass by pointer - pointer is assigned to passed value you can
pass **same type of derived type**.

Cases written above are safe conversion (no casting is needed). **C++
compiler will not allow any other conversion **. You can still use
casting for not allowed cases.

My doubts are
- Have I captured all the cases or there are some more cases (I will
appreciate a link to a small reference)

-What casts are safe e.g in case of pass by value casting from short to
int seems perfectly safe. (I will appreciate a link to any document
explaining safe casting)

thanks
Ittium
 
Reply With Quote
 
 
 
 
88888 Dihedral
Guest
Posts: n/a
 
      12-08-2011
On Thursday, December 8, 2011 4:17:22 PM UTC+8, Paavo Helde wrote:
> ittium <(E-Mail Removed)> wrote in news:jbplnk$qrf$(E-Mail Removed):
>
> > Groups,
> > I have few doubts regarding argument type of function and types,
> > arguments can handle safely.

>
> It depends on what you mean by "safely". It may mean a lot of things,
> starting from "the code is so clear, robust and self-contained that it
> will not need any change or refactoring in the next 30 years" up to "the
> argument content can be accessed safely from other threads while the
> first thread is sitting in this function call, but only in physically
> read-only mode, and until a given semaphore elsewhere in the code has not
> been signalled".
>
> > I know these issues have been discussed at
> > multiple places on internet. I wanted to see the big picture

>
> The big picture is that the language provides a multitude of different
> ways to pass information, each with their own trade-offs, and the
> programmer is obliged to select the correct one according to the actual
> needs. And the devil is in the details as always.
>
> >
> > When you pass by value - Copy constructor is called (except for basic
> > data type like int, float).

>
> Copy ctor calls may be elided by the compiler, even when it can cause
> visible side-effects.
>
> > you can pass the **same type variable** only
> >

>
> Nope, you can pass derived type objects as well, but they get sliced
> down. Not sure if this qualifies as "safely".
>


> A const reference can also bind to a temporary if direct binding is not
> possible, and there is a suitable conversion available. Some of the
> nastiest bugs I have seen were due to a (buggy) compiler binding a non-
> const reference to an automatically created temporary.
>


A small structure, say 16 to 128 bytes in the stack, is not big and can be
accessed efficiently than a big chunk of a multi-dimensional array that sits
on a heap classified in L2 or the lousy slow DRAM banks.

This assumes that the stack is accessed in L0 or L1 in the run time.

No deep stack probing and fat chunks in the heap is the reason to copy by
values of 16 to 128 bytes.

> > When you pass by pointer - pointer is assigned to passed value you can
> > pass **same type of derived type**.

>
> You ignore the const-non-const topic here, which for pointers is both
> simpler (no converted temporaries) and more complex (pointers themselves
> can be const or non-const, which turns especially tricky with several
> levels of indirection).
>
> >
> > Cases written above are safe conversion (no casting is needed). **C++
> > compiler will not allow any other conversion **. You can still use
> > casting for not allowed cases.

>
> Only if this does not make you code invalid
>
> >
> > My doubts are
> > - Have I captured all the cases or there are some more cases (I will
> > appreciate a link to a small reference)

>
> There certainly are; string literals and rvalue references pop in mind
> first.
>
> >
> > -What casts are safe e.g in case of pass by value casting from short to
> > int seems perfectly safe. (I will appreciate a link to any document
> > explaining safe casting)

>
> Much more tiny evil details. Short-to-int does not require a cast, at
> least not when signedness is the same. Otherwise, each cast has its own
> rules. Static_cast validness depends on the value you are casting.
> Const_cast validness may depend on a lot of things. Reinterpret_cast
> validness depends on the implementation details of the particular
> compiler and platform combination.
>
> Cheers
> Paavo


 
Reply With Quote
 
 
 
 
ittium
Guest
Posts: n/a
 
      12-08-2011
On 12/8/2011 1:47 PM, Paavo Helde wrote:
> ittium<(E-Mail Removed)> wrote in news:jbplnk$qrf$(E-Mail Removed):
>
>> Groups,
>> I have few doubts regarding argument type of function and types,
>> arguments can handle safely.

>
> It depends on what you mean by "safely". It may mean a lot of things,
> starting from "the code is so clear, robust and self-contained that it
> will not need any change or refactoring in the next 30 years" up to "the
> argument content can be accessed safely from other threads while the
> first thread is sitting in this function call, but only in physically
> read-only mode, and until a given semaphore elsewhere in the code has not
> been signalled".


Paavo, first thanks for the detailed response, for this discussion, by
safely I mean the type of arguments that can be passed to a argument
without any typecasting.

>
>> I know these issues have been discussed at
>> multiple places on internet. I wanted to see the big picture

>
> The big picture is that the language provides a multitude of different
> ways to pass information, each with their own trade-offs, and the
> programmer is obliged to select the correct one according to the actual
> needs. And the devil is in the details as always.
>
>>
>> When you pass by value - Copy constructor is called (except for basic
>> data type like int, float).

>
> Copy ctor calls may be elided by the compiler, even when it can cause
> visible side-effects.
>
>> you can pass the **same type variable** only
>>

>
> Nope, you can pass derived type objects as well, but they get sliced
> down. Not sure if this qualifies as "safely".


Thanks for pointing this out, yes I missed it. Atleast in the context of
this discussion, it is safe.

>
>> When you pass by reference - A reference will be intialized with pass
>> value. you can pass **non-const same type or derived type** (passing a
>> constant type will return in error)
>>
>> When you pass by constant reference you can pass **const/non-const of
>> same type or derived type**.

>
> A const reference can also bind to a temporary if direct binding is not
> possible, and there is a suitable conversion available. Some of the
> nastiest bugs I have seen were due to a (buggy) compiler binding a non-
> const reference to an automatically created temporary.
>
>>
>> When you pass by pointer - pointer is assigned to passed value you can
>> pass **same type of derived type**.

>
> You ignore the const-non-const topic here, which for pointers is both
> simpler (no converted temporaries) and more complex (pointers themselves
> can be const or non-const, which turns especially tricky with several
> levels of indirection).
>


yes I missed this topic, pointer to constant can accept pointer to
non-constant and but other way is not allowed. You are right, Pointer
itself can be constant. There will be many interesting cases when you
consider both value and the pointer to be const/non-const.

>>
>> Cases written above are safe conversion (no casting is needed). **C++
>> compiler will not allow any other conversion **. You can still use
>> casting for not allowed cases.

>
> Only if this does not make you code invalid


Absolutely, casting is like telling the compiler, I am more intelligent
than you and should be avoided.

>
>>
>> My doubts are
>> - Have I captured all the cases or there are some more cases (I will
>> appreciate a link to a small reference)

>
> There certainly are; string literals and rvalue references pop in mind
> first.


yes, If I have any doubt about these string literals/ravlue ask in the
group if I have doubts. I Request to all the group members who are
reading this post to add more cases if, I have missed any.

>>
>> -What casts are safe e.g in case of pass by value casting from short to
>> int seems perfectly safe. (I will appreciate a link to any document
>> explaining safe casting)

>
> Much more tiny evil details. Short-to-int does not require a cast, at
> least not when signedness is the same.


I am actually interested in all those cases where cast is not needed. I
will appreciate a reference to some link that covers all the cases where
casting is not required.

>Otherwise, each cast has its own
> rules. Static_cast validness depends on the value you are casting.
> Const_cast validness may depend on a lot of things. Reinterpret_cast
> validness depends on the implementation details of the particular
> compiler and platform combination.


Absolutely,
while writing code, I always try to avoid the casts, I have asked this
question so that I can take better decisions about (class/non-class)
method signatures.

>
> Cheers
> Paavo


 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      12-08-2011
On Thu, 2011-12-08, Paavo Helde wrote:
....
> The better "callability" does depend to some extent on the function
> signature, though logical simplicity and good names are far more
> important. Some rules related to signatures might be:
>
> - use const wherever possible (except top-level const which does not
> carry information)
> - use the same types as typical client code
> - avoid premature optimizations (which would make usage more difficult)
> - avoid unusual signatures
> - use return value for passing information out of the function, instead
> of modifying the arguments
> - signal errors with exceptions instead of error codes


I don't think this is a good idea, if it's an error which is likely to
happen and needs to be handled locally.

> - avoid hidden or global state inside (free) functions


But I agree with the rest.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
Goran
Guest
Posts: n/a
 
      12-09-2011
On Dec 8, 7:31*am, ittium <(E-Mail Removed)> wrote:
> Groups,
> I have few doubts regarding argument type of function and types,
> arguments can handle safely. I know these issues have been discussed at
> multiple places on internet. I wanted to see the big picture and needed
> opinion of C++ gurus
>
> When you pass by value - Copy constructor is called (except for basic
> data type like int, float).


I believe that it's better not to think like that. "basic" data types
are copied just as any other.

> you can pass the **same type variable** only


You can e.g. pass a smaller integral type (say, short) where bigger is
needed. You can also pass derived class instance where base is needed,
but you'll suffer from "object slicing". That might, or might not,
matter (it usually does).

> When you pass by reference - A reference will be intialized with pass
> value. you can pass **non-const same type or derived type** (passing a
> constant type will return in error)


Yes. Pass-by-ref is used when you want to change the parameter.

>
> When you pass by constant reference you can pass **const/non-const of
> same type or derived type**.


Yes. Purpose of this: to "design" through code and with the compiler's
help what is being changed where, all while avoiding copying a lot of
data around. (Pass by value designs the same thing, but suffers from a
performance hit when parameters are big or otherwise expensive to
copy).

> When you pass by pointer - pointer is assigned to passed value *you can
> pass **same type of derived type**.


Yes. Good C++ style is IMO to You pas by pointer to say: "here's a
reference to something, but it's __optional__ (it might be null).
There's little reason to use pointer parameters otherwise.

> Cases written above are safe conversion (no casting is needed). **C++
> compiler will not allow any other conversion **. You can still use
> casting for not allowed cases.
>
> My doubts are
> - Have I captured all the cases or there are some more cases (I will
> appreciate a link to a small reference)
>
> -What casts are safe e.g in case of pass by value casting from short to
> int seems perfectly safe. (I will appreciate a link to any document
> explaining safe casting)


Don't have a link, but... Pretty much none is safe. You have to
ensure, through code, that values are "convertible". In my mind, a
cast is a design error, especially between numbers. So that should be
fixed, and casts will go away .

Goran.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Variable argument function as a parameter of a variable argument function AikidoGuy C Programming 11 11-21-2011 10:43 PM
declaring a friend template function whose arguments are of type = private member type Hicham Mouline C++ 1 03-27-2009 03:58 PM
function argument dependent on another function argument? Reckoner Python 11 01-19-2009 03:31 AM
Safely casting pointer types, purpose of static_cast, etc. jason.cipriani@gmail.com C++ 5 06-08-2008 07:26 PM
how to pass a function name and its arguments inside the arguments of other function? jmborr Python 1 11-03-2007 08:20 AM



Advertisments