f



Argument type of function and safe types and types, arguments can handle safely

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
0
ittium (65)
12/8/2011 6:31:13 AM
comp.lang.c++ 49423 articles. 7 followers. Post Follow

7 Replies
1026 Views

Similar Articles

[PageSpeed] 21

ittium <ittium@gmail.com> wrote in news:jbplnk$qrf$1@dont-email.me:

> 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".

> 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).

> 
> 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
0
myfirstname1 (763)
12/8/2011 8:17:22 AM
On Thursday, December 8, 2011 4:17:22 PM UTC+8, Paavo Helde wrote:
> ittium <itt...@gmail.com> wrote in news:jbplnk$qrf$1...@dont-email.me:
> 
> > 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

0
12/8/2011 8:31:50 AM
On 12/8/2011 1:47 PM, Paavo Helde wrote:
> ittium<ittium@gmail.com>  wrote in news:jbplnk$qrf$1@dont-email.me:
>
>> 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

0
ittium (65)
12/8/2011 11:27:32 AM
ittium <ittium@gmail.com> wrote in news:jbq722$5dl$1@dont-email.me:

> 
> 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.

Well, this is much simpler question, although it depends somewhat on 
whether speed issues are important or not. The main goal is to keep the 
interfaces simple, both from the implementation and usage point of view, 
but preferring usage simplicity. This means for example that usage should 
not normally require any casts, if casts are required by any reason they 
should be encapsulated in the implementation. 

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
  - avoid hidden or global state inside (free) functions

These rules a bit contradictory in C++ because of a design flaw in the 
core (C) language: "const" should actually be the default and passing 
mutable parameters should require extra keywords instead. Currently 
writing conceptually simplest signatures means spraying 'const' all over 
the place.

There is a common habit to pass class objects by const reference instead 
of value. This might be considered a premature optimization and a 
complication of the signature, but as it does not usually affect the 
usage in any way I believe this would be OK. Actually, as this is so 
widespread then passing by value would actually go against the rule 
"avoid unusual signatures".

If speed is important, these rules will be slightly modified and the 
interfaces may become more complex.

hth
Paavo
0
myfirstname1 (763)
12/8/2011 6:32:18 PM
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   .
0
nntp24 (1801)
12/8/2011 8:00:15 PM
Jorgen Grahn <grahn+nntp@snipabacken.se> wrote in
news:slrnje25qf.q8l.grahn+nntp@frailea.sa.invalid: 

> On Thu, 2011-12-08, Paavo Helde wrote:
>>   - 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.

Yes, if something is handled locally, it is simpler to use an error code 
than to set up a try-catch block. And if something is not handled locally, 
then it is simpler to use a try-catch block upstream than to check for 
error codes everywhere.

And if speed is important, one must take into account that exception 
throwing might be quite expensive operation so one may have to use error 
codes or equivalent even for non-local handling if the "error" may appear 
often.

Trade-offs as usual.

Cheers
Paavo
0
myfirstname1 (763)
12/8/2011 8:30:26 PM
On Dec 8, 7:31=A0am, ittium <itt...@gmail.com> 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 =A0you 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.
0
goran.pusic (304)
12/9/2011 11:05:28 AM
Reply:

Similar Artilces:

Function '>=' is not defined for arguments of type 'date' and 'integer'. Explicitly convert its arguments to the desired type(s)
Hi all, I'm getting the following error message while comparing dates in Ingres database Function '>=' is not defined for arguments of type 'date' and 'integer'. Explicitly convert its arguments to the desired type(s) I feel that it has to do something with table definition. Here is my query: Select * from my_table where valid_date >= another_date; Can any one throw light on this. Thanks, Sen "Sen" <senthil.dhanapal@gmail.com> wrote > Hi all, > > I'm getting the following error message while comparing...

Handling incomplete type for automated formal in-argument type
I just coded up the following to automate selection of a type for a formal in-argument: namespace impl { template< class Type > constexpr auto is_large_or_incomplete() -> bool { return (sizeof_<Type>() == 0 ? true : sizeof_<Type>() > sizeof( Ptr_<void> ) ); } } // namespace impl template< class Arg > using In_ = If_< Any_of_< Is_true_<impl::is_large_or_incomplete<Arg>()...

Intel error: type of actual argument differs from type of dummy argument
I have my numeric kinds defined as follows: integer, parameter, public :: sp = kind(1.0) integer, parameter, public :: dp = selected_real_kind(2*precision(1.0_sp)) integer, parameter, public :: qp_preferred = & selected_real_kind(2*precision(1.0_dp)) integer, parameter, public :: qp = (1+sign(1,qp_preferred))/2*qp_preferred+ & (1-sign(1,qp_preferred))/2*dp Then, somewhere in a module for constants, i have pi defined as: real(kind=qp), parameter, public :: pi = & 3.141592653589793238462643...

Format expects argument of type char but argument _ has type int
I've been stuck on this. Now, bare in mind, I am still a beginner. I'm ce= rtain there are more efficient ways to code this, but I am writing this for= an assignment and just need help resolving my strings from being promoted = to integers. argh! script: Script started on Mon 30 Sep 2013 11:18:46 PM EDT redo.c: In function =91main=92: redo.c:101:1: warning: format =91%s=92 expects argument of type =91char *= =92, but argument 2 has type =91int=92 [-Wformat] redo.c:101:1: warning: format =91%s=92 expects argument of type =91char *= =92, but argument 3 has type ...

How to make a function work with different type and kind type argument
Hi, the intrinsic sin(x), cos(x), etc, work with arguments of general type and kind type. Suppose I want to write a function mysin(x) which just calls sin(x) and, like sin(x), must work with general type and kind type argument. I can achieve the generality of type through overloading, however how can I obtain generality of kind type? Best regards, deltaquattro deltaquattro wrote: > Hi, > > the intrinsic sin(x), cos(x), etc, work with arguments of general type > and kind type. Suppose I want to write a function mysin(x) which just > calls sin(x) and, like sin(x), must work ...

declaring a friend template function whose arguments are of type = private member type
hello, I have template<typename CurveTraits> class TimeCurve1D { public: typedef typename CurveTraits::tType tType; typedef typename CurveTraits::fType fType; fType GetSomething() const; private: typedef std::pair<tType,fType> EntryType; typedef boost::array< EntryType, mContainerMaxSize > ContainerType; ContainerType m; size_t mContainerSize; }; In GetSomething(), I use std::lower_bound( &m[0], &m[mContainerMaxSize], std::pair<t, NaN> ) lower_bound uses operator< by default Where can I defined this operator< for EntryType? and how c...

What is the purpose of type() and the types module and what is a type?
The type() builtin according to python docs, returns a "type object". http://docs.python.org/2/library/types.html And in this module is bunch of what I assume are "type objects". Is this correct? http://docs.python.org/2/library/functions.html#type And type(), aside from being used in as an alternative to a class statement to create a new type, really just returns the object class, doesn't it? >>> import types >>> a = type(1) >>> b = (1).__class__ >>> c = int >>> d = types.IntType >>> a is b is c is...

proper type conversion between PTRDIFF and a type where I can see the type
I know this is a c++ message board rather than a windows one, but my issue may be more related to type conversion (which is probably closer to c++). I'm trying to convert/cast for example, dpwszFamilyName member of IFIMETRICS structure from PTRDIFF type into a type where I can read and process the type. How would you suggest me to go about on achieving this objective? ...

Tagged type more type safe than access to subprogram ?
Hello Ada Artists, I was reading the Ada 95 Quality and Style Guide, seeking for some inspiration about a design / style doubt. I came into Chapter 5, =93 CHAPTER 5: Programming Practices =94, 5.3.4 Subprogram Access Types says : > You can achieve the same effect as access-to-subprogram types for > dynamic selection by using abstract tagged types. You declare an > abstract type with one abstract operation and then use an > access-to-class-wide type to get the dispatching effect. This technique > provides greater flexibility and type safety than access-to-subprogram ty= pes He...

how to make a function with argument type 'REAL' accept variabl with type 'REAL(selected_real_kind(8) )' ?
I'm writing a program using both HOMPACK90 and the IMSL function S_BS2VL. The problem is that HOMPACK90 require all real variables declared REAL(kind=R8), for this I declare the variable as REAL(selected_real_kind(8)) and it works ok with HOMPACK90 , but when this variable used as an argument into S_BS2VL(...) it won't accept it, though its argument is supposed to be REAL. The compiler said " The kind (8) of this actual argument does not match that of its associated dummy argument (4)" . Anyone knows how to make it work? Thank you very much Yiyu shenyiyu@gmail.com (Yiyu S...

Function-type arguments in function definition
Hi, I'm pretty new to Mathematica so please excuse me if this is kind of a silly question (though I couldn't find any answer after a full day of searching). I'm trying to define functions that take other functions as arguments and need those functions' arguments in their own definition. An example would be the definition of convolution: h(x)=f(x)*g(x) is defined as Integral over f(y)g(x-y) with respect to y. As you can see it is important in the definition of convolution to treat the arguments f and g as functions because the definition makes use of their argumen...

Samples for non-type template argument other than integral types
In TC++PL Special Edition, template parameters section, page 332, second paragraph said: �A template argument can be a constant expression, the address of an object or function with external linkage, or a non-overloaded pointer to member.� I have used type parameters and also constant expressions as non-type template arguments in my programs. Now, I am experimenting with further possibilities from the other types of template arguments. By now, I have successfully experiment with the following: * the address of an object * the address of a function with external linkage, * a non-overloaded po...

Incomplete type in template parameter, complete type as argument
I've got a somewhat strange situtation, and while I have a solution, I'm curious about the legality of my first attempted solution, purely templates. (G++ doesn't compile it, but I can't decide whether the problem is in my code, or a bug in g++). Basically, the code is: template< typename T, size_t N > T* begin( T (&array)[ N ] ) { return array ; } template< typename T, size_t N > T* end( T (&array)[ N ] ) { return array + N ; } struct Match { explicit ...

How to duplicate the dynamic type of an abstract type dummy argument
Hi all, consider the following code: type, abstract :: c_ode ! ... end type c_ode ! ... subroutine s(x,y) class(c_ode), intent(in) :: x class(c_ode), intent(out) :: y class(c_ode), allocatable :: tmp allocate(tmp,source=x) ! ... end subroutine s From Fortran 95/2003 explained, by Metcalf, Reid, Cohen, I understand that after the sourced allocation tmp is a clone of x, meaning that it has the same dynamic type and value of x. Is it possible to allocate tmp so that it has the same dynamic type of x, without copying the value? Thank you again, Marco m <mrestelli@gmail....

Web resources about - Argument type of function and safe types and types, arguments can handle safely - comp.lang.c++

Tax protester administrative arguments - Wikipedia, the free encyclopedia
Tax protesters in the United States make a number of administrative arguments that the assessment of the federal income tax in the United States ...

'The most hurtful argument in the marriage equality debate...': Penny Wong
Labor frontbencher Penny Wong is used to to hearing arguments against same-sex marriage. But for Australia's most prominent gay politician - ...

Donald Trump makes the religious argument at Liberty University
CBS News Donald Trump makes the religious argument at Liberty University CBS News LYNCHBURG, Virginia Before GOP presidential candidate Donald ...

The Moment You Realize You're Argument Is Weak
Can't play video Submitted by: (via s4w ) Tagged: gif , FAIL , Cats , fall Share on Facebook

Liberal Senator Says She Wants To Avoid ‘Constitutional Arguments’ During Hearing On Obama’s Executive ...
Liberal Senator Says She Wants To Avoid ‘Constitutional Arguments’ During Hearing On Obama’s Executive Gun Action

End of the road for arguments presented by Sweden, UK: Assange on UN panel verdict
Julian Assange called for Britain and Sweden to "implement" a UN panel finding saying that he should be able to walk free from Ecuador's embassy. ...

OK, I'll Bite: The Anti-Fiscal Policy Argument
Paul Krugman sets us the task of coming up with a non-ridiculous anti-fiscal policy argument. Because, you know, recent experience shows us that ...

Federal Court to Hear Arguments in Transgender Restroom Case
A federal appeals court will hear arguments in a Virginia transgender student's lawsuit challenging his school's restroom policy

Tom Benson, estranged heirs make arguments in appeals hearing on Saints, Pelicans owner's competency
Lawyers for New Orleans Saints and Pelicans owner Tom Benson and his estranged heirs made arguments Thursday in the appeals hearing regarding ...

The Sexualization Of Harry Styles: Arguments For And Against
Yesterday The Inquisitr outlined some arguments in favour of the sexualization of One Direction star Harry Styles. This issue has provoked controversy ...

Resources last updated: 2/8/2016 3:07:45 AM