By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,608 Members | 3,801 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,608 IT Pros & Developers. It's quick & easy.

operator new with "value type"

P: n/a

Hello,

I'm a developer coming from C++ and Java ... I've going thru
"Effective C#" (which highly recommend for people coming from other
languages wanting to learn C#), and it states that "value types" are
always created on the stack, but then showed the "creation" of one w/
operator new. I guess it makes sense, but is it true that:

MyValueType t;

and

MyValueType t = new MyValueType();

are equivalent w/ regard to where the object is stored? That just
seems odd to me. I suppose this is probably in a FAQ somewhere (I
welcome any pointers to any FAQ list that answers this), but I
couldn't find it stated obviously (tho I didn't spend too long
looking :) ...

-Charlie
Dec 7 '07 #1
Share this Question
Share on Google+
24 Replies


P: n/a
On Fri, 07 Dec 2007 12:22:29 -0800, carnold <Ch************@gmail.com
wrote:
[...] I guess it makes sense, but is it true that:

MyValueType t;

and

MyValueType t = new MyValueType();

are equivalent w/ regard to where the object is stored? That just
seems odd to me.
To me too. But yes, the two are equivalent with respect to where the data
is stored. It just happens that the value types use the "new" operator
for initializing even though no actual memory is allocated in that case.

Pete
Dec 7 '07 #2

P: n/a
carnold <Ch************@gmail.comwrote:
I'm a developer coming from C++ and Java ... I've going thru
"Effective C#" (which highly recommend for people coming from other
languages wanting to learn C#), and it states that "value types" are
always created on the stack
If it says exactly that, then it's wrong.
See http://pobox.com/~skeet/csharp/memory.html
but then showed the "creation" of one w/
operator new. I guess it makes sense, but is it true that:

MyValueType t;

and

MyValueType t = new MyValueType();

are equivalent w/ regard to where the object is stored?
Yes. The value of the variable is an instance of MyValueType, and it's
stored wherever the context of the variable is.
That just seems odd to me.
I think it makes perfect logical sense, but it *is* different to C++.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk
Dec 7 '07 #3

P: n/a
On Fri, 07 Dec 2007 15:57:17 -0800, carnold <Ch************@gmail.com>
wrote:
[...]
It's a well understood design principal that you shouldn't change the
meaning of familiar constructs.
It's also well-understood that it's okay to have behaviors that are
different represented by the same syntax, as long as the behavior is
similar enough. That's why operator overloading, and even overloading of
methods, is not only but valuable in many cases.

It's not an either/or, black-and-white question.
"new" has specific implications in
both C++ and Java that don't hold in C# ... I guarantee you I'm not
the first one to think changing those implications a bad idea.
You don't need to guarantee him. He knows. He's heard me complain about
the very same thing in the past. :)

I still wish that a different syntax had been used, but I do understand
the basis for those who say that using "new" is better than other
alternatives. I don't necessarily agree, but I'm not the one who got to
design the language and the issue is too subjective for me to claim
there's an absolute truth to be found.

Pete
Dec 8 '07 #4

P: n/a
Just as a minor comment on the "new" thing... the use of the same
keyword certainly help keep things consistent when considering
generics... if there were two operators, then it would be a little
less clear what "new T()" meant for "SomeMethod<T>() where T : new()".
(I'm mainly thinking of default values, and "not found" return values
in the "bool TrySomething(out T)" pattern).

Yes, value-types have different behavior - but that isn't really
limited just to construction. They behave differently as method
arguments, for instance - yet the syntax is identical there... I'm not
sure it makes much benefit to single out construction for special
syntax. Personally I'm happy with the shared syntax, but I appreciate
that there is a little bit of a learning curve.

Marc
Dec 8 '07 #5

P: n/a
On Sat, 08 Dec 2007 00:23:15 -0800, Marc Gravell <ma**********@gmail.com>
wrote:
Just as a minor comment on the "new" thing... the use of the same
keyword certainly help keep things consistent when considering
generics... if there were two operators, then it would be a little
less clear what "new T()" meant for "SomeMethod<T>() where T : new()".
(I'm mainly thinking of default values, and "not found" return values
in the "bool TrySomething(out T)" pattern).
Yup, that's true. Anyone arguing against using "new" to initialize a
struct should be forced to come up with a suitable alternative syntax so
that a generic class or method that has to initialize/instantiate some
instance of one or more type parameters for the generic can still be done
without caring whether the type is a value or reference type.

So, do I have an alternative syntax? No, not at the moment. I'll get
back to you. :)
Yes, value-types have different behavior - but that isn't really
limited just to construction. They behave differently as method
arguments, for instance - yet the syntax is identical there... I'm not
sure it makes much benefit to single out construction for special
syntax. Personally I'm happy with the shared syntax, but I appreciate
that there is a little bit of a learning curve.
It doesn't bother me that much now. In fact, it never really created a
significant problem for me, per se. The main problem was that it for a
little while led me to believe a few types were classes instead of
structs. I also have a vague memory of some sort of uninitialized
variable error that was somehow related to this "new" business, but at the
moment I can't actually remember why it was related (whatever it was, it
was more complicated than just "oh, you need new to initialize your value
type" but I don't recall the details).

But it didn't cause me any hard-to-figure out coding problems and of
course I eventually got better at thinking value-vs-reference type without
getting confused by the overlapping syntax.

I can't say I would ever lobby hard to change the syntax. But I do have
sympathy for those who feel compelled to complain about it. :) And
believe me, if I had a good idea for how to deal with that situation
better, I'd talk about it. I do see the benefit in the current syntax,
and I have no suggestions for something better. But that doesn't mean I
have to like it. :)

Pete
Dec 8 '07 #6

P: n/a
Lew
carnold <Ch************@gmail.comwrote:
>It's a well understood design principal [sic] that you shouldn't change the
meaning of familiar constructs. "new" has specific implications in
both C++ and Java that don't hold in C#
If that were true no language would look different from FORTRAN.

The trouble with saying "it's ... well understood" is that the passive voice
construction begs the question of *who* understands it. I sure didn't. And I
used to program in FORTRAN for a living. Face it, different languages have
different meanings for things that superficially are similar. (References
since C++, generics between Java and C#, to name two.)

In fact, within FORTRAN itself there were changes within "familiar
constructs". A loop index variable was scoped to the loop in some dialects,
but wider in others. The newer languages changed the meaning of the familiar
construct of "scope", and made it explicit, thus fixing a lot of weird bugs.

Jon Skeet said:
Another change from C++ and Java: you can't fall through from one
switch case to another (although you can have multiple labels for the
same case). Is that a bad idea too? It removes a common source of
errors.
Another case where it's a well-understood design principle that one should
change the meaning of familiar constructs, sometimes.

--
Lew
Dec 9 '07 #7

P: n/a
The main problem was that it for a
little while led me to believe a few types were classes instead of
structs.
I agree that this can be a pain, and it is *so* important to know if
you are talking about a class or a struct - I'm lazy, so I simply
change the IDE color of the various "User Types (...)" items; my
"Value Types" are in magenta, for example. Very helpful when you are
working with something unfamiliar.

(it obviously doesn't help with keyword aliases (int vs string), but
I'm pretty sure I know all of those ;-p)

Marc
Dec 9 '07 #8

P: n/a
Another change from C++ and Java: you can't fall through from one
switch case to another (although you can have multiple labels for the
same case). Is that a bad idea too? It removes a common source of
errors.
Ahh, but you *can* fall-through when you need to, using "goto case". The
best of both worlds -- protection against stupid errors, and the ability to
do what you need where you need it. Even a rather intuitive syntax for
letting the compiler know that the out-of-the-ordinary was intended.
Dec 11 '07 #9

P: n/a
On Dec 11, 4:09 pm, "Ben Voigt [C++ MVP]" <r...@nospam.nospamwrote:
Another change from C++ and Java: you can't fall through from one
switch case to another (although you can have multiple labels for the
same case). Is that a bad idea too? It removes a common source of
errors.

Ahh, but you *can* fall-through when you need to, using "goto case". The
best of both worlds -- protection against stupid errors, and the ability to
do what you need where you need it. Even a rather intuitive syntax for
letting the compiler know that the out-of-the-ordinary was intended.
True - but I wouldn't personally call "explicitly saying where to go
next" as fall-through :)

(One slight pity about the C# 3 spec is that in one place where it
shows how C# has removed a common source of C++ errors, it uses an if
without braces - demonstrating how a completely different source of C+
+ errors is still alive and kicking in C#!)

Jon
Dec 11 '07 #10

P: n/a
Hi,
--
Ignacio Machin
http://www.laceupsolutions.com
Mobile & warehouse Solutions.
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:e81c0e05-37c1-4cbb-9495-
(One slight pity about the C# 3 spec is that in one place where it
shows how C# has removed a common source of C++ errors, it uses an if
without braces - demonstrating how a completely different source of C+
+ errors is still alive and kicking in C#!)
I have never seem that error, have you?
Dec 11 '07 #11

P: n/a
<"Ignacio Machin \( .NET/ C# MVP \)" <machin TA laceupsolutions.com>>
wrote:
>(One slight pity about the C# 3 spec is that in one place where it
shows how C# has removed a common source of C++ errors, it uses an
if without braces - demonstrating how a completely different source
of C++ errors is still alive and kicking in C#!)
I have never seem that error, have you?
Yes, I have. Basically code which ended up reading:

if (someExpression)
FirstStatement();
SecondStatement();

but should have read:

if (someExpression)
{
FirstStatement();
SecondStatement();
}

Not my code, of course, but I a bug I fixed :)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk
Dec 11 '07 #12

P: n/a

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP*********************@msnews.microsoft.com. ..
<"Ignacio Machin \( .NET/ C# MVP \)" <machin TA laceupsolutions.com>>
wrote:
>>(One slight pity about the C# 3 spec is that in one place where it
shows how C# has removed a common source of C++ errors, it uses an
if without braces - demonstrating how a completely different source
of C++ errors is still alive and kicking in C#!)
>I have never seem that error, have you?

Yes, I have. Basically code which ended up reading:

if (someExpression)
FirstStatement();
SecondStatement();

but should have read:

if (someExpression)
{
FirstStatement();
SecondStatement();
}

Not my code, of course, but I a bug I fixed :)
python programmers...
>
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

Dec 13 '07 #13

P: n/a
Jon Skeet [C# MVP] wrote:
<"Ignacio Machin \( .NET/ C# MVP \)" <machin TA laceupsolutions.com>>
wrote:
>>(One slight pity about the C# 3 spec is that in one place where it
shows how C# has removed a common source of C++ errors, it uses an
if without braces - demonstrating how a completely different source
of C++ errors is still alive and kicking in C#!)
>I have never seem that error, have you?

Yes, I have. Basically code which ended up reading:

if (someExpression)
FirstStatement();
SecondStatement();

but should have read:

if (someExpression)
{
FirstStatement();
SecondStatement();
}

Not my code, of course, but I a bug I fixed :)
It must have happen hundred of thousands of times.

The programmer writes:

if (someExpression)
SecondStatement();

He figure out that he does not need the { } because it is only
one statement.

Then later another statement has to be added and because it is a bit
hectic at the time then it end up as:

if (someExpression)
FirstStatement();
SecondStatement();

And suddenly some things stop working.

Arne
Dec 24 '07 #14

P: n/a
Lew wrote:
In fact, within FORTRAN itself there were changes within "familiar
constructs". A loop index variable was scoped to the loop in some
dialects, but wider in others. The newer languages changed the meaning
of the familiar construct of "scope", and made it explicit, thus fixing
a lot of weird bugs.
Fortran 90/95 ?

Not possible in 66 and 77.
(I know that C++ had such a problem before ANSI standardization)

Arne
Dec 24 '07 #15

P: n/a
Hi,
Interesting, it might be the case that I have not seen that much code that
was not mine :)

It would be overkill to force the use of { though.

"Arne Vajhj" <ar**@vajhoej.dkwrote in message
news:47***********************@news.sunsite.dk...
Jon Skeet [C# MVP] wrote:
> <"Ignacio Machin \( .NET/ C# MVP \)" <machin TA laceupsolutions.com>>
wrote:
>>>(One slight pity about the C# 3 spec is that in one place where it
shows how C# has removed a common source of C++ errors, it uses an if
without braces - demonstrating how a completely different source of C++
errors is still alive and kicking in C#!)
>>I have never seem that error, have you?

Yes, I have. Basically code which ended up reading:

if (someExpression)
FirstStatement();
SecondStatement();

but should have read:

if (someExpression)
{
FirstStatement();
SecondStatement();
}

Not my code, of course, but I a bug I fixed :)

It must have happen hundred of thousands of times.

The programmer writes:

if (someExpression)
SecondStatement();

He figure out that he does not need the { } because it is only
one statement.

Then later another statement has to be added and because it is a bit
hectic at the time then it end up as:

if (someExpression)
FirstStatement();
SecondStatement();

And suddenly some things stop working.

Arne
Dec 24 '07 #16

P: n/a
<"Ignacio Machin \( .NET/ C# MVP \)" <machin TA laceupsolutions.com>>
wrote:
Interesting, it might be the case that I have not seen that much code that
was not mine :)

It would be overkill to force the use of { though.
Would it really? I certainly find code much more readable that way, and
it *is* required for various constructs IIRC.

I use them everywhere, and haven't found any disadvantages to it.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk
Dec 24 '07 #17

P: n/a

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP*********************@msnews.microsoft.com. ..
<"Ignacio Machin \( .NET/ C# MVP \)" <machin TA laceupsolutions.com>>
wrote:
>Interesting, it might be the case that I have not seen that much code
that
was not mine :)

It would be overkill to force the use of { though.

Would it really? I certainly find code much more readable that way, and
it *is* required for various constructs IIRC.
do-while and switch require the braces
>
I use them everywhere, and haven't found any disadvantages to it.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

Dec 24 '07 #18

P: n/a
Ben Voigt [C++ MVP] wrote:
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP*********************@msnews.microsoft.com. ..
<"Ignacio Machin \( .NET/ C# MVP \)" <machin TA laceupsolutions.com>>
wrote:
Interesting, it might be the case that I have not seen that much code
that
was not mine :)

It would be overkill to force the use of { though.
Would it really? I certainly find code much more readable that way, and
it *is* required for various constructs IIRC.

do-while and switch require the braces
---8<---
class App
{
static void Main()
{
do System.Console.WriteLine(); while(false);
}
}
--->8---

C# switch does require braces, although consider C/C++:

---8<---
int main(void)
{
switch (0);
return 0;
}
--->8---

(I in no way condone use of the above forms; though I'm ambivalent about
requiring {} on if-statement sub-blocks.)

-- Barry

--
http://barrkel.blogspot.com/
Dec 25 '07 #19

P: n/a
Lew
Arne Vajhøj wrote:
Lew wrote:
>In fact, within FORTRAN itself there were changes within "familiar
constructs". A loop index variable was scoped to the loop in some
dialects, but wider in others. The newer languages changed the
meaning of the familiar construct of "scope", and made it explicit,
thus fixing a lot of weird bugs.

Fortran 90/95 ?

Not possible in 66 and 77.
(I know that C++ had such a problem before ANSI standardization)
I don't remember which version of FORTRAN scoped loop variables to the loop
for you, but it was in 1980. The reason was optimization - the loop variable
could be enregistered. The register would be colored by a different variable
immediately after loop exit.

--
Lew
Dec 26 '07 #20

P: n/a
Lew wrote:
Arne Vajhøj wrote:
>Lew wrote:
>>In fact, within FORTRAN itself there were changes within "familiar
constructs". A loop index variable was scoped to the loop in some
dialects, but wider in others. The newer languages changed the
meaning of the familiar construct of "scope", and made it explicit,
thus fixing a lot of weird bugs.

Fortran 90/95 ?

Not possible in 66 and 77.

(I know that C++ had such a problem before ANSI standardization)

I don't remember which version of FORTRAN scoped loop variables to the
loop for you, but it was in 1980. The reason was optimization - the
loop variable could be enregistered. The register would be colored by a
different variable immediately after loop exit.
Are you sure you remember correct ?

Declarations in Fortran (at least the old versions) are always
before executable statements and therefor with subroutine/function
wide scope. I would assume that implicit declared variable would be
the same.

And AFAIK the Fortran standard explicitly define that the loop
variable to be last value + step after the do loop.

Arne

Dec 27 '07 #21

P: n/a

"Barry Kelly" <ba***********@gmail.comwrote in message
news:q1********************************@4ax.com...
Ben Voigt [C++ MVP] wrote:
>"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP*********************@msnews.microsoft.com ...
<"Ignacio Machin \( .NET/ C# MVP \)" <machin TA laceupsolutions.com>>
wrote:
Interesting, it might be the case that I have not seen that much code
that
was not mine :)

It would be overkill to force the use of { though.

Would it really? I certainly find code much more readable that way, and
it *is* required for various constructs IIRC.

do-while and switch require the braces

---8<---
class App
{
static void Main()
{
do System.Console.WriteLine(); while(false);
}
}
--->8---
Ok, you win. I have *never* before seen a do-while without braces in either
C#, C++, or plain C.
>
C# switch does require braces, although consider C/C++:

---8<---
int main(void)
{
switch (0);
return 0;
}
--->8---

(I in no way condone use of the above forms; though I'm ambivalent about
requiring {} on if-statement sub-blocks.)

-- Barry

--
http://barrkel.blogspot.com/

Dec 28 '07 #22

P: n/a
Ben Voigt [C++ MVP] <rb*@nospam.nospamwrote:

<snip>
Ok, you win. I have *never* before seen a do-while without braces in either
C#, C++, or plain C.
I hope I never see one in production code, either :)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk
Dec 28 '07 #23

P: n/a
Ben Voigt [C++ MVP] wrote:
"Barry Kelly" <ba***********@gmail.comwrote in message
> do System.Console.WriteLine(); while(false);
Ok, you win. I have *never* before seen a do-while without braces in either
C#, C++, or plain C.
Neither have I.

But considering that in Pascal you can even do multiple
statements in a repeat until loop without begin end blocks,
then it should not be that surprising.

Arne
Dec 28 '07 #24

P: n/a
Arne Vajhj wrote:
Ben Voigt [C++ MVP] wrote:
"Barry Kelly" <ba***********@gmail.comwrote in message
do System.Console.WriteLine(); while(false);
Ok, you win. I have *never* before seen a do-while without braces in either
C#, C++, or plain C.

Neither have I.

But considering that in Pascal you can even do multiple
statements in a repeat until loop without begin end blocks,
then it should not be that surprising.
It isn't like Pascal - in C/etc., the logic is that a *single* statement
is expected between the 'do' and the 'while', so the parser code looks
very roughly like this (in LL recursive descent):

case DO:
Skip(DO);
body = ParseStatement();
Expect(WHILE);
// etc...

It could have been rewritten to something like:

case DO:
Skip(DO);
body = ParseBlockStatement();
Expect(WHILE);
// etc...

.... but it never has, for reasons unknown.

-- Barry

--
http://barrkel.blogspot.com/
Dec 30 '07 #25

This discussion thread is closed

Replies have been disabled for this discussion.