473,324 Members | 2,193 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,324 software developers and data experts.

conversion syntax

REH
It it permissible to use the constructor style cast with primitives
such as "unsigned long"? One of my compilers accepts this syntax, the
other does not. The failing one chokes on the fact that the type is
not a single identifier or keyword. Which one is correct? For example:

unsigned long x = unsigned long(y);

REH
Oct 8 '08 #1
21 2407
REH wrote:
It it permissible to use the constructor style cast with primitives
such as "unsigned long"? One of my compilers accepts this syntax, the
other does not. The failing one chokes on the fact that the type is
not a single identifier or keyword. Which one is correct? For example:

unsigned long x = unsigned long(y);
If I'm not mistaken, if you want to make a C-style cast to a type
which consists of several keywords, you have to enclose them in
parentheses. That is:

unsigned long x = (unsigned long)(y);

Of course the recommended way in C++ is to use a C++ style cast:

unsigned long x = static_cast<unsigned long>(y);
Oct 8 '08 #2
REH
On Oct 8, 10:36*am, Juha Nieminen <nos...@thanks.invalidwrote:
REH wrote:
It it permissible to use the constructor style cast with primitives
such as "unsigned long"? One of my compilers accepts this syntax, the
other does not. The failing one chokes on the fact that the type is
not a single identifier or keyword. Which one is correct? For example:
unsigned long x = unsigned long(y);

* If I'm not mistaken, if you want to make a C-style cast to a type
which consists of several keywords, you have to enclose them in
parentheses. That is:

* * unsigned long x = (unsigned long)(y);

* Of course the recommended way in C++ is to use a C++ style cast:

* * unsigned long x = static_cast<unsigned long>(y);
Thanks. I know. I was just wondering if the constructor style was
legal.

Oct 8 '08 #3
On Oct 8, 3:36*pm, Juha Nieminen <nos...@thanks.invalidwrote:
REH wrote:
It it permissible to use the constructor style cast with primitives
such as "unsigned long"? One of my compilers accepts this syntax, the
other does not. The failing one chokes on the fact that the type is
not a single identifier or keyword. Which one is correct? For example:
unsigned long x = unsigned long(y);

* If I'm not mistaken, if you want to make a C-style cast to a type
which consists of several keywords, you have to enclose them in
parentheses. That is:

* * unsigned long x = (unsigned long)(y);

* Of course the recommended way in C++ is to use a C++ style cast:

* * unsigned long x = static_cast<unsigned long>(y);
The original question, IMO, involved C++ functional style cast, rather
than C-style cast.

--
Max
Oct 8 '08 #4
REH wrote:
Thanks. I know. I was just wondering if the constructor style was
legal.
Well, it is legal as long as your type consists of one single symbol.
For example this will always be legal:

template<typename T>
void foo()
{
T x = T(y);
}

This even if you call it like foo<unsigned long>(). That's because 'T'
is just one symbol.

Rather curiously, this is legal too:

template<typename T>
void foo()
{
T x = (T)y;
}

And this even if T is a class (with a constructor which takes a
parameter of the type of 'y').

Oct 8 '08 #5
REH <sp******@stny.rr.comwrites:
It it permissible to use the constructor style cast with primitives
such as "unsigned long"? One of my compilers accepts this syntax, the
other does not. The failing one chokes on the fact that the type is
not a single identifier or keyword. Which one is correct? For example:

unsigned long x = unsigned long(y);
Well, C++ syntax is rather complex. It's understandable it's hard to
read, to understand and therefore to implement correctly. I don't
know what is specified there.

Since you observe that's a hard dark corner with diverging
implementation, my advice would be to avoid it. Or to use parentheses.

typedef unsigned long ulong;
ulong x = ulong(y);

or:

unsigned long x = (unsigned long)(y);
--
__Pascal Bourguignon__
Oct 8 '08 #6
REH
On Oct 8, 10:47*am, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
REH <spamj...@stny.rr.comwrites:
It it permissible to use the constructor style cast with primitives
such as "unsigned long"? One of my compilers accepts this syntax, the
other does not. The failing one chokes on the fact that the type is
not a single identifier or keyword. Which one is correct? For example:
unsigned long x = unsigned long(y);

Well, C++ syntax is rather complex. *It's understandable it's hard to
read, to understand and therefore to implement correctly. * I don't
know what is specified there.

Since you observe that's a hard dark corner with diverging
implementation, my advice would be to avoid it. *Or to use parentheses.

* * typedef unsigned long ulong;
* * ulong x = ulong(y);

or:

* * unsigned long x = (unsigned long)(y);

--
__Pascal Bourguignon__
Sigh. Yes, I know that. My question is simply: is the syntax legal or
not?

REH
Oct 8 '08 #7
Maxim Yegorushkin <ma***************@gmail.comwrites:
On Oct 8, 3:36*pm, Juha Nieminen <nos...@thanks.invalidwrote:
>REH wrote:
It it permissible to use the constructor style cast with primitives
such as "unsigned long"? One of my compilers accepts this syntax, the
other does not. The failing one chokes on the fact that the type is
not a single identifier or keyword. Which one is correct? For example:
unsigned long x = unsigned long(y);

* If I'm not mistaken, if you want to make a C-style cast to a type
which consists of several keywords, you have to enclose them in
parentheses. That is:

* * unsigned long x = (unsigned long)(y);

* Of course the recommended way in C++ is to use a C++ style cast:

* * unsigned long x = static_cast<unsigned long>(y);

The original question, IMO, involved C++ functional style cast, rather
than C-style cast.
Which funnily, is not decided when you write:

unsigned long x = (unsigned long)(y);

The compiler could as well decide to parse it as a C cast as a C++
functional style cast. I think it'll be my favorite way to write it,
let the compiler deal with it as it wants :-)

--
__Pascal Bourguignon__
Oct 8 '08 #8
REH
On Oct 8, 11:29*am, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
Maxim Yegorushkin <maxim.yegorush...@gmail.comwrites:
On Oct 8, 3:36*pm, Juha Nieminen <nos...@thanks.invalidwrote:
REH wrote:
It it permissible to use the constructor style cast with primitives
such as "unsigned long"? One of my compilers accepts this syntax, the
other does not. The failing one chokes on the fact that the type is
not a single identifier or keyword. Which one is correct? For example:
unsigned long x = unsigned long(y);
* If I'm not mistaken, if you want to make a C-style cast to a type
which consists of several keywords, you have to enclose them in
parentheses. That is:
* * unsigned long x = (unsigned long)(y);
* Of course the recommended way in C++ is to use a C++ style cast:
* * unsigned long x = static_cast<unsigned long>(y);
The original question, IMO, involved C++ functional style cast, rather
than C-style cast.

Which funnily, is not decided when you write:

* * unsigned long x = (unsigned long)(y);

The compiler could as well decide to parse it as a C cast as a C++
functional style cast. * I think it'll be my favorite way to write it,
let the compiler deal with it as it wants :-)
Maxim understands that it was a question about syntax, not semantics.

REH
Oct 8 '08 #9
REH
On Oct 8, 10:29*am, REH <spamj...@stny.rr.comwrote:
It it permissible to use the constructor style cast with primitives
such as "unsigned long"? One of my compilers accepts this syntax, the
other does not. The failing one chokes on the fact that the type is
not a single identifier or keyword. Which one is correct? For example:

unsigned long x = unsigned long(y);
OK, if I read the sections in the standard defining "simple-type-
specifier" and "postfix-expression" correctly, the syntax is not
valid.

REH
Oct 8 '08 #10
REH
On Oct 8, 11:29*am, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
Which funnily, is not decided when you write:

* * unsigned long x = (unsigned long)(y);

The compiler could as well decide to parse it as a C cast as a C++
functional style cast. * I think it'll be my favorite way to write it,
let the compiler deal with it as it wants :-)
It don't matter how you write it, when there is a valid conversion
from T to U, these are all equivalent:

U(T);
(U) T;
static_cast<U>(T);
REH
Oct 8 '08 #11
On 2008-10-08 12:38:20 -0400, REH <sp******@stny.rr.comsaid:
On Oct 8, 11:29Â*am, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
>Which funnily, is not decided when you write:

Â* Â* unsigned long x = (unsigned long)(y);

The compiler could as well decide to parse it as a C cast as a C++
functional style cast. Â* I think it'll be my favorite way to write it,
let the compiler deal with it as it wants :-)

It don't matter how you write it, when there is a valid conversion
from T to U, these are all equivalent:

U(T);
(U) T;
static_cast<U>(T);

It does matter what you write. The second also applies to situations
where the others don't, and some people think that this leads to errors.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

Oct 8 '08 #12
REH
On Oct 8, 12:41*pm, Pete Becker <p...@versatilecoding.comwrote:
On 2008-10-08 12:38:20 -0400, REH <spamj...@stny.rr.comsaid:
On Oct 8, 11:29*am, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
Which funnily, is not decided when you write:
* * unsigned long x = (unsigned long)(y);
The compiler could as well decide to parse it as a C cast as a C++
functional style cast. * I think it'll be my favorite way to write it,
let the compiler deal with it as it wants :-)
It don't matter how you write it, when there is a valid conversion
from T to U, these are all equivalent:
U(T);
(U) T;
static_cast<U>(T);

It does matter what you write. The second also applies to situations
where the others don't, and some people think that this leads to errors.
I use "doesn't matter" to mean when the three versions valid, change
from one to the other will not produce a different meaning. I agree
that c-style casts can be dangerous.

REH
Oct 8 '08 #13
On Oct 8, 5:29 pm, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
Maxim Yegorushkin <maxim.yegorush...@gmail.comwrites:
On Oct 8, 3:36 pm, Juha Nieminen <nos...@thanks.invalidwrote:
REH wrote:
It it permissible to use the constructor style cast with
primitives such as "unsigned long"? One of my compilers
accepts this syntax, the other does not. The failing one
chokes on the fact that the type is not a single
identifier or keyword. Which one is correct? For example:
unsigned long x = unsigned long(y);
If I'm not mistaken, if you want to make a C-style cast to
a type which consists of several keywords, you have to
enclose them in parentheses.
Not a C-style cast; an "explicit type conversion (functional
notation)". The sytax for this requires either a
simple-type-specifier or a typename-specifier to the left of the
parentheses. A simple-type-specifier can be either a single
token, or a qualified type name, e.g. X::Y::Z. It cannot be the
name of a type which requires several tokens to specify, so the
answer to his question is no.
That is:
unsigned long x = (unsigned long)(y);
Of course the recommended way in C++ is to use a C++ style cast:
unsigned long x = static_cast<unsigned long>(y);
Recommended by whom? I've never seen code which didn't use the
functional notation for type conversion; if the number of
arguments is anything other than one, it's the only type of type
conversion which works. I'd strongly recommend using the new
cast syntax for pointer and reference casts, but for the others,
I generally use either a C style cast or the functional
notation.
The original question, IMO, involved C++ functional style
cast, rather than C-style cast.
Which funnily, is not decided when you write:
unsigned long x = (unsigned long)(y);
Yes it is. That's an "explicit type conversion (cast
notation)"---a C style cast. The functional notation has a
particularity that the others don't have: you can convert
nothing, or more than one thing:-). (And yes, calling it a
conversion is a bit strange, but that's what the standard does.)
So given a user defined type A:

A() explicit type conversion (functional notation)
(A)() illegal
static_cast< A >() illegal

A( x ) explicit type conversion (functional notation)
(A)( x ) explicit type conversion (cast notation)
static_cast< A >( x ) static_cast

A( x, y ) explicit type conversion (functional notation)
(A)( x, y ) illegal
static_cast< A >( x, y ) illegal

In each group of three, all of the legal syntaxes have exactly
the same semantics (and note that A(x) doesn't necessarily call
the constructor of A---it can also call a user defined coversion
operator of x).
The compiler could as well decide to parse it as a C cast as a
C++ functional style cast. I think it'll be my favorite way
to write it, let the compiler deal with it as it wants :-)
Personally, I think it would have been clearer if the cast
notation had been extended to allow multiple arguments, and the
function style casts hadn't been introduced. That would have
eliminated a lot of ambiguities. But it's too late for that
now.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Oct 8 '08 #14
REH
On Oct 8, 12:51*pm, James Kanze <james.ka...@gmail.comwrote:
Not a C-style cast; an "explicit type conversion (functional
notation)". *The sytax for this requires either a
simple-type-specifier or a typename-specifier to the left of the
parentheses. *A simple-type-specifier can be either a single
token, or a qualified type name, e.g. X::Y::Z. *It cannot be the
name of a type which requires several tokens to specify, so the
answer to his question is no.
Thank you, Mr. Kanze.

REH
Oct 8 '08 #15
James Kanze wrote:
>>> unsigned long x = (unsigned long)(y);
>>> Of course the recommended way in C++ is to use a C++ style cast:
>>> unsigned long x = static_cast<unsigned long>(y);

Recommended by whom?
By people who think that converting between incompatible types (in
other words, reinterpret-casting) when that's not your intention is a
bad idea, and that it's better to use the casting which will make the
compiler complain.

The problem with the C-style cast is that it converts almost anything
to almost anything else, which is seldom what you want to do. Usually
you only want to cast between compatible types.
Oct 8 '08 #16
In article <f9**************@read4.inet.fi>,
Juha Nieminen <no****@thanks.invalidwrote:
[...]
The problem with the C-style cast is that it converts almost anything
to almost anything else, which is seldom what you want to do. Usually
you only want to cast between compatible types.
And sadly, C++-style functional casts have this same danger.
Oct 8 '08 #17
On Oct 8, 8:41*pm, Juha Nieminen <nos...@thanks.invalidwrote:
James Kanze wrote:
>>* * unsigned long x = (unsigned long)(y);
>>* Of course the recommended way in C++ is to use a C++ style cast:
>>* * unsigned long x = static_cast<unsigned long>(y);
Recommended by whom?
By people who think that converting between incompatible types
(in other words, reinterpret-casting) when that's not your
intention is a bad idea, and that it's better to use the
casting which will make the compiler complain.
Which is only relevant if there are pointers or references
involved, since all reinterpret_cast's involve pointers and
references.

As I said, I've yet to see any code in which the author avoided
things like "MyClass( x )". Which is a function style cast, and
could be rewritten "static_cast< MyClass >( x )", or things like
"MyClass()" or "MyClass( x, y )", which are function style
classes, and can't be expressed any other way.
The problem with the C-style cast is that it converts almost
anything to almost anything else, which is seldom what you
want to do. Usually you only want to cast between compatible
types.
There is, IMHO, a very definite psychological distinction.
Unless the target type is a reference, a type conversion creates
a new temporary object. In practice, however, with pointer
conversions, we normally think in terms of the pointed to object
(i.e. almost as if it were a reference), and there are several
different conversions possible. So we want a syntax to 1) state
explicitly which conversion we want, and 2) be highly visible
and easy to find, because we are going to access an object in an
unusual way. When converting between numeric types, on the
other hand (e.g. an int to an unsigned long), neither of these
issues are relevant, and we (or I, at least) think of it more
along the same lines as we do things like MyClass( x ). In
other words, a function style cast. Except that if we cannot
name the target type with a single word, we have to add
parentheses around it, which turns it into a C style cast.

In practice, I'll never use a C style cast or a functional style
cast for a pointer or a reference, and I'll almost never use
anything but a functional style cast when explicitly creating a
temporary object of class type (converting to a class type); for
numeric types, I tend to use functional or C style casts, but
I'll occasionally use a static_cast too.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Oct 8 '08 #18
On Oct 8, 9:26*pm, blargg <blargg....@gishpuppy.comwrote:
In article <f97Hk.165$V%4...@read4.inet.fi>,
*Juha Nieminen <nos...@thanks.invalidwrote:
[...]
The problem with the C-style cast is that it converts almost
anything to almost anything else, which is seldom what you
want to do. Usually you only want to cast between compatible
types.
And sadly, C++-style functional casts have this same danger.
Except that the danger is only really present if the target type
is a pointer or a reference, and functional casts can't be used
in such cases.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Oct 8 '08 #19
James Kanze wrote:
On Oct 8, 9:26 pm, blargg <blargg....@gishpuppy.comwrote:
>In article <f97Hk.165$V%4...@read4.inet.fi>,
Juha Nieminen <nos...@thanks.invalidwrote:
[...]
>>The problem with the C-style cast is that it converts almost
anything to almost anything else, which is seldom what you
want to do. Usually you only want to cast between compatible
types.
>And sadly, C++-style functional casts have this same danger.

Except that the danger is only really present if the target type
is a pointer or a reference, and functional casts can't be used
in such cases.
I consider this
enum colors { red, green, blue };
colors c = colors(10);
dangerous.

Schobi
Oct 9 '08 #20
On Oct 10, 2:17*am, James Kanze <james.ka...@gmail.comwrote:
On Oct 9, 10:50 am, Hendrik Schober <spamt...@gmx.dewrote:
James Kanze wrote:
On Oct 8, 9:26 pm, blargg <blargg....@gishpuppy.comwrote:
>In article <f97Hk.165$V%4...@read4.inet.fi>,
>*Juha Nieminen <nos...@thanks.invalidwrote:
>[...]
>>The problem with the C-style cast is that it converts
>>almost anything to almost anything else, which is seldom
>>what you want to do. Usually you only want to cast between
>>compatible types.
>And sadly, C++-style functional casts have this same danger.
Except that the danger is only really present if the target
type is a pointer or a reference, and functional casts can't
be used in such cases.
* I consider this
* * enum colors { red, green, blue };
* * colors c = colors(10);
* dangerous.

In the same sense that
* * int i = int( 3.14159 ) ;
is dangerous, yes. *In the case of user defined types, you could
do some runtime checking, but only if you overloaded enough to
avoid the implicit conversions. *Because in the end, if you have
MyClass, with a constructor which takes an int, what is the
different between:
* * int i = int( 3.14159 ) ;
and
* * MyClass c( 3.14159 ) ;

There is, IMHO, a real problem in that many such dangerous
conversions are not only allowed, but happen implicitly. *IIRC,Stroustrup wanted to change this at one point, but the committee
wouldn't follow him. *So we're more or less stuck with them.
More or less, but only more or less. In C++0x we'll get the uniform
initialization syntax and semantics based on { }, and that doesn't
allow narrowing, so

int i1 = int( 3.14159 ) ; // ok (unfortunately)
int i2 = 3.14; // ok (unfortunately)
int i3 = int{3.14}; // error: narrowing
int i3{3.14}; // error: narrowing

colors c1 = colors(10); // ok (unfortunately)
colors c2 = colors{10}; // error: narrowing

Bjarne Stroustrup; http://www.research.att.com/~bs
Oct 12 '08 #21
bjarne wrote:
[...]
More or less, but only more or less. In C++0x we'll get the uniform
initialization syntax and semantics based on { }, and that doesn't
allow narrowing, so

int i1 = int( 3.14159 ) ; // ok (unfortunately)
int i2 = 3.14; // ok (unfortunately)
int i3 = int{3.14}; // error: narrowing
int i3{3.14}; // error: narrowing

colors c1 = colors(10); // ok (unfortunately)
colors c2 = colors{10}; // error: narrowing

Bjarne Stroustrup; http://www.research.att.com/~bs
Sounds good to me.

Schobi
Oct 14 '08 #22

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

7
by: Michael Lehn | last post by:
Hi, I have a question regarding the conversion of objects. When is the conversion done by the constructor and when by the operator. My feeling tells me that the constructor is preferred. But...
11
by: Peter Oliphant | last post by:
I've been trying all morning to convert my 2003 project (managed) to 2005 (/clr since I have both managed and unmanaged code). I'm guessing I have tens of thousands of lines of code to change. Did...
47
by: rawCoder | last post by:
Hi, Just wanted to know if there is any speed difference between VB conversion Keywords like CInt, Clng, CStr, CDbl, CBool etc. ..NETs Convert.To<...> methods. And which is better to be...
1
by: Michael Tissington | last post by:
I'm trying to convert a project from VS2003 to VS2005 After conversion all of my TagPrefix are not recognized in the body. <%@ Register TagPrefix="Oaklodge" TagName="Curve"...
14
by: Richard G. Riley | last post by:
Would it be wrong to use "implicit casting" instead of the standards "implicit conversion" when talking about implicit conversions between certain data types. The standard mentions "explicit...
0
by: Lou Evart | last post by:
DOCUMENT CONVERSION SERVICES Softline International (SII) operates one of the industry's largest document and data conversion service bureaus. In the past year, SII converted over a million...
8
by: Smithers | last post by:
Are there any important differences between the following two ways to convert to a type?... where 'important differences' means something more profound than a simple syntax preference of the...
1
by: drop | last post by:
Hi all, I'd like to know if it's possible to declare an implicit type conversion for when I use declarative Synthax in html. For example, when I have the DropDownList, I can declatively set...
5
by: Randy | last post by:
I've converted a VS 2003 project to VS 2005. I have one utility class that it put in the APP_CODE directory. When I try and compile I'm getting this error... Error 1 The type or namespace name...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.