3

Possible Duplicate:
What is the difference between (type)value and type(value)?

I am mainly a C# developer and so do a lot of explicit casting using syntax like: (type)variable, with (int)100.0004d as an example. As such, when writing code in C++, I often use the same syntax. However, I have seen (and even used) code in other cases where the same cast is achieved using the syntax type(variable) with int(100.0004) as an example.

I was just curious as to what the difference between the two methods were and whether there were any implications in using one over the other.

Example:

double someDouble = 100.00456;

// Cast the double using the (type)variable syntax
int firstCastValue = (int)someDouble;

// Cast the double using the type(variable) syntax
int secondCastValue = int(someDouble);
Community
  • 1
  • 1
Samuel Slade
  • 8,405
  • 6
  • 33
  • 55

3 Answers3

8

The two are exactly the same, and this is true for any type.

Personally, I would avoid the first form, (T)x, in favour of an explicit static cast:

y = static_cast<T>(x);

This expresses that you want to convert x to the type T.

The second form is rather more evocative of a constructor call, and that's sometimes preferable:

v = std::vector<int>(10);  // not: v = static_cast<std::vector<int>>(10)

To repeat, both forms are entirely equivalent, and it's a matter of taste which you prefer. I would use static cast for "converting" and constructor-syntax for "constructing", if that makes any sense.

Kerrek SB
  • 464,522
  • 92
  • 875
  • 1,084
  • So a call `Foo(arg)` where `Foo` is of class type can call the default constructor then conversion operator? – Kos Jan 16 '12 at 14:13
  • 3
    @Kos: Only one of the two. Either `Foo` is constructible from `arg`, *or* `arg` has a conversion operator to `Foo`. If both are defined then it's ambiguous. – Kerrek SB Jan 16 '12 at 14:16
2

None. They're exactly the same. But this is C++, and you should not use C-style casts between types. static_cast<int>(someDouble) is what you're looking for.

Cat Plus Plus
  • 125,936
  • 27
  • 200
  • 224
  • 1
    except when an implicit conversion is possible, without warnings. `intvar = doublevar` is more elegant than `intvar = static_cast(doublevar)` since it's clear that this is a standard conversion rather than something you have to force. – Mr Lister Jan 16 '12 at 14:19
  • 1
    ...with the caveat that there's an odd corner case where a C-style cast is the only one that'll work (conversion to inaccessible base class). I'd also add that avoiding the cast (at all) is much more important than the syntax you use for the cast when you do use one. – Jerry Coffin Jan 16 '12 at 14:21
  • @JerryCoffin Can you give an example where none of the C++ casts work? – Mr Lister Jan 16 '12 at 14:38
  • @MrLister: You might want to read a [previous post](http://stackoverflow.com/questions/2488418/should-i-pointer-cast-from-a-private-derived-class-to-its-base-class/2488525) that asked about it. – Jerry Coffin Jan 16 '12 at 14:49
  • `reinterpret_cast` works over there. I thought you meant that none of the C++ style casts works, and you needed a C style cast to make it work. – Mr Lister Jan 16 '12 at 14:58
  • @MrLister: A `reinterpret_cast` will let the code compile, but *does not* (necessarily) work correctly. In particular, with multiple inheritance, it can only work correctly for conversion to one of the base classes. – Jerry Coffin Jan 16 '12 at 15:22
1

They will do the same operation. However,

  • (int)someDouble is a C-style cast, which is discouraged in C++. Don't use it. Ever.
  • int(someDouble) syntax is not a cast as such, it's an explicit request to create a temporary. It allows creating temporary using constructor with more than 1 argument and creating a temporary using explicit constructor. On the other hand it does not allow casting to types that are not named by single identifier (so no pointers, no unsigned long etc.). Normally used when your intention is really to have a temporary of some complex type, i.e. one with non-trivial constructor.
  • static_cast<int>(someDouble) is what you really should use most of the time. It will cast between any convertible types and between pointers of related types only. Which is what you should limit yourself to most of the time.

There are other flavors of *_cast, namely:

  • dynamic_cast<Something *>(pAnything) will check at runtime that the pointer actually points to the specified type and return NULL if it does not. Also usable with references like dynamic_cast<Something &>(anything) in which case it throws a std::bad_cast exception if it is not of the correct type. This is like the C# anything as Something.
  • const_cast<Something *>(constSomething) is only capable of removing const qualifier; the other *_cast will refuse to. If you need this, you have design problem.
  • reinterpret_cast<Something *>(pUnrelated) will cast unrelated pointers. Since in C++ a pointer cast is not necessarily a trivial operation (adds/subtracts offset for multiply-inherited objects), it is usually a bad idea and should only be used if you are doing something clever. In fact I am not sure there is a use of reinterpret_cast that would not violate "strict aliasing rules" and therefore be platform-dependent. The reason that C-style cast decays to reinterpret cast when the pointers are unrelated is why it should never be used.
Jan Hudec
  • 73,652
  • 13
  • 125
  • 172
  • @JerryCoffin: They are not deprecated by the standard, but by many coding guidelines, because of all the reasons why the other cast styles were introduced. Saying "discouraged" is probably better; editing. – Jan Hudec Jan 16 '12 at 15:10