423,850 Members | 1,555 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 423,850 IT Pros & Developers. It's quick & easy.

Verifiable methods and C# language rule about local variable

P: n/a
A few days ago I started a thread "I think C# is forcing us to write
more (redundant) code" and got many replies (more than what I had
expected). But after reading all the replies I think my question about
local variable initialization is still not solved. And some of the
replies forked into talking about out parameters. And the thread is
becoming way too deep.

So I open a new thread here. My question in the previous thead has
turned into this question:

Does the CIL spec enforce all compilers that target CLR must generate
verifiable methods?

If the anwser to the above question is true, I think C# language spec is
in an unfortunate situation.

I understand that the designers try to inherit C/C++ advantages and
strong points over other languages - uninitialized local variables
enables speed and flexibility.

But in the .NET world, this advantage seems no longer exist or has
degraded into a useless a feature that might cause performance problem.

Although it is only a few CPU cycles, but it is enough to arouse the
sensitivity amongh any of experienced C/C++ programmers (and most of
them choose C# as the programming language for the .NET platform).

I know C# language spec has already been submitted as a 'standard', and
it is very unlikely that the rule about unitialization of local
variables will be changed in a near future (or never). But I would like
to express my *discomfort* about some aspects about the C# language
design (I will be very happy if C# has a VB-like with/end with
construct). That makes me feel good.
Nov 17 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a

"Edward Yang" <ne***********@msn.com> wrote in message
news:%2***************@tk2msftngp13.phx.gbl...
A few days ago I started a thread "I think C# is forcing us to write more
(redundant) code" and got many replies (more than what I had expected). But
after reading all the replies I think my question about local variable
initialization is still not solved. And some of the replies forked into
talking about out parameters. And the thread is becoming way too deep.

So I open a new thread here. My question in the previous thead has turned
into this question:

Does the CIL spec enforce all compilers that target CLR must generate
verifiable methods?
No. I believe verifiability is a matter of security, not of raw
implementation. Many machines would refuse to run unverifiable code, and
alot of unverifable code might not work, it is not illegal to run
unverifiable code. The CLS only covers completely verifable constructs, but
few langauges produce only code using only CLS compliant constructs.
I know C# language spec has already been submitted as a 'standard', and it
is very unlikely that the rule about unitialization of local variables
will be changed in a near future (or never). But I would like to express
my *discomfort* about some aspects about the C# language design (I will be
very happy if C# has a VB-like with/end with construct). That makes me
feel good.


I never had any issue with the rules on initalization. They just are'nt that
big a deal. Sure they cost a couple cycles, but they are virutally
non-existant when compared to the time lost to the GC, runtime setup, etc.

I am also quite happy that 'with' never was added.
Nov 17 '05 #2

P: n/a

"Edward Yang" <ne***********@msn.com> wrote in message
news:%2***************@tk2msftngp13.phx.gbl...
A few days ago I started a thread "I think C# is forcing us to write more
(redundant) code" and got many replies (more than what I had expected). But
after reading all the replies I think my question about local variable
initialization is still not solved. And some of the replies forked into
talking about out parameters. And the thread is becoming way too deep.

So I open a new thread here. My question in the previous thead has turned
into this question:

Does the CIL spec enforce all compilers that target CLR must generate
verifiable methods?
No. I believe verifiability is a matter of security, not of raw
implementation. Many machines would refuse to run unverifiable code, and
alot of unverifable code might not work, it is not illegal to run
unverifiable code. The CLS only covers completely verifable constructs, but
few langauges produce only code using only CLS compliant constructs.
I know C# language spec has already been submitted as a 'standard', and it
is very unlikely that the rule about unitialization of local variables
will be changed in a near future (or never). But I would like to express
my *discomfort* about some aspects about the C# language design (I will be
very happy if C# has a VB-like with/end with construct). That makes me
feel good.


I never had any issue with the rules on initalization. They just are'nt that
big a deal. Sure they cost a couple cycles, but they are virutally
non-existant when compared to the time lost to the GC, runtime setup, etc.

I am also quite happy that 'with' never was added.
Nov 17 '05 #3

P: n/a

"Edward Yang" <ne***********@msn.com> wrote in message
news:%2***************@tk2msftngp13.phx.gbl...
A few days ago I started a thread "I think C# is forcing us to write more
(redundant) code" and got many replies (more than what I had expected). But
after reading all the replies I think my question about local variable
initialization is still not solved. And some of the replies forked into
talking about out parameters. And the thread is becoming way too deep.

So I open a new thread here. My question in the previous thead has turned
into this question:

Does the CIL spec enforce all compilers that target CLR must generate
verifiable methods?
No, the CIL doesn't enforce this, but the runtime might refuse to run
non-verifiable methods depending where they were loaded from (unless you
turn off the security check - or worse, turn off the complete security
system in the CLR).
If the anwser to the above question is true, I think C# language spec is
in an unfortunate situation.

Compared to what other languages?
Microsoft compilers [1] can only produce verifiable code, that means they
all opted to set the localsinit flag in the method headers, this is a choice
made by the compiler folks, note also that the C# compiler is used to build
the BCL and FCL and these folks (and I guess everyone else) wanted the
library to be safe and verifiable.

[1] C#, VB.NET, J# and (VS2005) C++/CLI in safe mode (clr:safe)

Following compilers do not produce verifiable code.
C++/CLI with /clr:pure and /clr:oldsyntax option set.
ME C++ .
Note that C++/CLI (VS2005) is the succesor of the ME C++ compiler (VS2003)

I understand that the designers try to inherit C/C++ advantages and strong
points over other languages - uninitialized local variables enables speed
and flexibility.
I think you are wrong, it was not the intention of the C# designer to
achieve the same level of efficiency and performance as C++, just like it
was not the intention of StrousTrup to the achieve the level of efficiency
of C when he invented C++, just like it was not the intention of the devs.
at Bell labs to achieve the same level of efficiency as assembly language
code when they invented B and later C. No, A. Hejlsberg (and S. Wiltamuth,
and P. Golde) intention was to produce a simple, modern, typesafe, pure
object oriented, flexible language that could be used as a general purpose
RAD programming tool achieving a reasonably performance level (>80%)
compared to native (C/C++) code. Sure, both C and C++ have their strong
points, but they have also some very weak points, and it was one of the
intentions of the inventors of the Java language at Sun and the C# devs at
MS to remove these weak points and keep the strong points where possible.
But in the .NET world, this advantage seems no longer exist or has
degraded into a useless a feature that might cause performance problem.
If you think it's useless, and you think the few cycles may cause you
performance problems, you should think again because you are wrong.
But if you can prove you are right, I'm affraid all there is left to do is
go back to C and/or assembly.
Although it is only a few CPU cycles, but it is enough to arouse the
sensitivity amongh any of experienced C/C++ programmers (and most of them
choose C# as the programming language for the .NET platform).
The cycles lost to initialize the locals are nothing compared to the cycles
needed to generate and execute managed type safe code under the CLR.
Honestly, you are focusing too much on the language and more precisely on
this paticular issue, the language is not key in .NET, it's the runtime the
class library and it's features.
There are places in YOUR code where you might have saved thousands of cycles
if you had choosen another algorithm, or if you had selected the right
container for your objects. Everyone will make wrong choices ( unless you
are a programming God, but he! they use assembly) burn thousands (Millions?)
of cycles and when performance sucks and after they profiled and correct the
problem, (maybe?) they won't make this 'same' mistake again and live an
happy life, but they won't care about the two cycles needed to initialize a
local (even not die hard C programmers like me).

To give you something else to think about, you probably know that some of
the C library functions like printf, sprintf etc...are intrinsically unsafe
(buffer overflow issue). Microsoft decided to add a safe equivalents to the
C runtime library, they are safer at the expense of CPU cycles, so they are
less performant. The upcoming version of the CLR (which uses the C runtime)
uses these "safe string" functions, you ain't gonna start arguing about this
I suppose? The CLR includes several other reliability, safety and security
measures to protect you and the system as a whole from nasty issues, these
measures burn a thousands of CPU cycles, the few cycles taken by "locals
init" are dust, believe me.
I know C# language spec has already been submitted as a 'standard', and it
is very unlikely that the rule about unitialization of local variables
will be changed in a near future (or never). Again this is another issue, the C# imposed requirement of explicit
assignment before use, has nothing to do with the initialization done by the
"locals init" directive. The C# language could relax this issue by
generating a warning, but heck, you still have to take some (corrective?)
actions if you want to get rid of the warnings.
Again, next version of VB.NET generates a warning for un-assigned locals,
which is a good thing as it say's "he! are you sure this variable shouldn't
be assigned a value?"
< But I would like to express my *discomfort* about some aspects about the C# language design
(I will be very happy if C# has a VB-like with/end with construct). That
makes me feel good.


I for one would be unhappy with this addition of with/end construct, it
doesn't add anything valuable to the language, and the addition of two
keywords makes me shiver. You know, no programming language is perfect, if
this is what you are looking for, I'm afraid you will have to build your
own, but before you start, many have tried before and no-one ever succeeded
;-)

Willy.


Nov 17 '05 #4

P: n/a
Thanks for your reply. You spent a considerable time on my problem.
Thanks again.

What you said is all reasonable. I am that kind of person that sometimes
becomes very critic about something. In this case I really think the C#
language spec is enforcing a useless rule - it's not about practical
things; it's all about theory. C/C++ may have its weakness, which is a
thing I cannot understand. But weakness != uselessness. That's my point.

I won't argue with you any more, only with one exception. If C# is going
to have a VB like With/End With construct, it needs only *one*
additional keyword - with, for example:

with(this.control1.collection1[0].property1.subitem1)
{
.name = "Neo";
.age = 99;
}

I know I can use a temporary variable (that is the workaround posted to
the feedback on With/End With construct). But that's NOT what I want - I
want a builtin language construct.
BTW, I don't think the number of keywords is a big problem. Yes, C/C++
has a very small set of keywords, but it also implies a number of
quasi-keywords (or language construct). What is the syntax of pure
virutal methods? You know what I mean.

Willy Denoyette [MVP] wrote:
"Edward Yang" <ne***********@msn.com> wrote in message
news:%2***************@tk2msftngp13.phx.gbl...
A few days ago I started a thread "I think C# is forcing us to write more
(redundant) code" and got many replies (more than what I had expected). But
after reading all the replies I think my question about local variable
initialization is still not solved. And some of the replies forked into
talking about out parameters. And the thread is becoming way too deep.

So I open a new thread here. My question in the previous thead has turned
into this question:

Does the CIL spec enforce all compilers that target CLR must generate
verifiable methods?


No, the CIL doesn't enforce this, but the runtime might refuse to run
non-verifiable methods depending where they were loaded from (unless you
turn off the security check - or worse, turn off the complete security
system in the CLR).

If the anwser to the above question is true, I think C# language spec is
in an unfortunate situation.

Compared to what other languages?
Microsoft compilers [1] can only produce verifiable code, that means they
all opted to set the localsinit flag in the method headers, this is a choice
made by the compiler folks, note also that the C# compiler is used to build
the BCL and FCL and these folks (and I guess everyone else) wanted the
library to be safe and verifiable.

[1] C#, VB.NET, J# and (VS2005) C++/CLI in safe mode (clr:safe)

Following compilers do not produce verifiable code.
C++/CLI with /clr:pure and /clr:oldsyntax option set.
ME C++ .
Note that C++/CLI (VS2005) is the succesor of the ME C++ compiler (VS2003)
I understand that the designers try to inherit C/C++ advantages and strong
points over other languages - uninitialized local variables enables speed
and flexibility.


I think you are wrong, it was not the intention of the C# designer to
achieve the same level of efficiency and performance as C++, just like it
was not the intention of StrousTrup to the achieve the level of efficiency
of C when he invented C++, just like it was not the intention of the devs.
at Bell labs to achieve the same level of efficiency as assembly language
code when they invented B and later C. No, A. Hejlsberg (and S. Wiltamuth,
and P. Golde) intention was to produce a simple, modern, typesafe, pure
object oriented, flexible language that could be used as a general purpose
RAD programming tool achieving a reasonably performance level (>80%)
compared to native (C/C++) code. Sure, both C and C++ have their strong
points, but they have also some very weak points, and it was one of the
intentions of the inventors of the Java language at Sun and the C# devs at
MS to remove these weak points and keep the strong points where possible.

But in the .NET world, this advantage seems no longer exist or has
degraded into a useless a feature that might cause performance problem.


If you think it's useless, and you think the few cycles may cause you
performance problems, you should think again because you are wrong.
But if you can prove you are right, I'm affraid all there is left to do is
go back to C and/or assembly.

Although it is only a few CPU cycles, but it is enough to arouse the
sensitivity amongh any of experienced C/C++ programmers (and most of them
choose C# as the programming language for the .NET platform).


The cycles lost to initialize the locals are nothing compared to the cycles
needed to generate and execute managed type safe code under the CLR.
Honestly, you are focusing too much on the language and more precisely on
this paticular issue, the language is not key in .NET, it's the runtime the
class library and it's features.
There are places in YOUR code where you might have saved thousands of cycles
if you had choosen another algorithm, or if you had selected the right
container for your objects. Everyone will make wrong choices ( unless you
are a programming God, but he! they use assembly) burn thousands (Millions?)
of cycles and when performance sucks and after they profiled and correct the
problem, (maybe?) they won't make this 'same' mistake again and live an
happy life, but they won't care about the two cycles needed to initialize a
local (even not die hard C programmers like me).

To give you something else to think about, you probably know that some of
the C library functions like printf, sprintf etc...are intrinsically unsafe
(buffer overflow issue). Microsoft decided to add a safe equivalents to the
C runtime library, they are safer at the expense of CPU cycles, so they are
less performant. The upcoming version of the CLR (which uses the C runtime)
uses these "safe string" functions, you ain't gonna start arguing about this
I suppose? The CLR includes several other reliability, safety and security
measures to protect you and the system as a whole from nasty issues, these
measures burn a thousands of CPU cycles, the few cycles taken by "locals
init" are dust, believe me.

I know C# language spec has already been submitted as a 'standard', and it
is very unlikely that the rule about unitialization of local variables
will be changed in a near future (or never).


Again this is another issue, the C# imposed requirement of explicit
assignment before use, has nothing to do with the initialization done by the
"locals init" directive. The C# language could relax this issue by
generating a warning, but heck, you still have to take some (corrective?)
actions if you want to get rid of the warnings.
Again, next version of VB.NET generates a warning for un-assigned locals,
which is a good thing as it say's "he! are you sure this variable shouldn't
be assigned a value?"
< But I would like
to express my *discomfort* about some aspects about the C# language design
(I will be very happy if C# has a VB-like with/end with construct). That
makes me feel good.

I for one would be unhappy with this addition of with/end construct, it
doesn't add anything valuable to the language, and the addition of two
keywords makes me shiver. You know, no programming language is perfect, if
this is what you are looking for, I'm afraid you will have to build your
own, but before you start, many have tried before and no-one ever succeeded
;-)

Willy.

Nov 17 '05 #5

P: n/a
On Thu, 1 Sep 2005 14:13:23 +0200, "Willy Denoyette [MVP]"
<wi*************@telenet.be> wrote:
I think you are wrong, it was not the intention of the C# designer to
achieve the same level of efficiency and performance as C++, just like it
was not the intention of StrousTrup to the achieve the level of efficiency
of C when he invented C++, just like it was not the intention of the devs.
at Bell labs to achieve the same level of efficiency as assembly language
code when they invented B and later C.


While I agree with most of your post, your historical comments here
are wrong. Stroustrup did in fact attempt to "provide Simula's
facilities for program organization together with C's efficiency and
flexibility for systems programming" [1], and C was specifically
designed to replace assembly as a systems programming language, which
of course implied retaining as much efficiency as possible.

Also note how C data types map directly to hardware: strings are
merely zero-terminated byte sequences, int and long change width
depending on the underlying hardware, floating-point ops may be
unsupported if the underlying hardware doesn't have them. C/C++
aren't called portable assembly languages for no reason. :)

[1] Bjarne Stroustrup: The Design and Evolution of C++, Introduction.
--
http://www.kynosarges.de
Nov 17 '05 #6

P: n/a

"Christoph Nahr" <ch************@kynosarges.de> wrote in message
news:lv********************************@4ax.com...
On Thu, 1 Sep 2005 14:13:23 +0200, "Willy Denoyette [MVP]"
<wi*************@telenet.be> wrote:
I think you are wrong, it was not the intention of the C# designer to
achieve the same level of efficiency and performance as C++, just like it
was not the intention of StrousTrup to the achieve the level of efficiency
of C when he invented C++, just like it was not the intention of the devs.
at Bell labs to achieve the same level of efficiency as assembly language
code when they invented B and later C.
While I agree with most of your post, your historical comments here
are wrong. Stroustrup did in fact attempt to "provide Simula's
facilities for program organization together with C's efficiency and


Obviously, it was one of Stroustrup's goals to achieve a comparable level of
efficiency as C when he invented C++. But don't tell me that it was it's
primary goal. C++ is a complex language, it's a lot more complicated to
parse and optimize than C, the existing compilers (front-ends and back-ends)
are not comparable with what existed 10-20 years ago, current C++ compiler
would even load or run on 20 year old systems. So whether this goal was met
20 years ago is debatable, my experiences tell me it wasn't so.
flexibility for systems programming" [1], and C was specifically
designed to replace assembly as a systems programming language, which
of course implied retaining as much efficiency as possible.
Agreed, as much as possible but not the same, that's what I said in another
posting, C (a higher level assembly language) is still the systems
programming language of choice in cases where you don't need the C++ OO
features, but you realy need the highest level control/efficiency, again
this is more a tooling issue than a pure language issue. I know you can
hardly write more efficient code in C than in C++ if you are using the same
compilers and libraries. The point is that some specialized libraries aren't
written in C++, because there is no need for it's feature set. In another
thread I gave the example of Device driver or OS kernel development, where
even the standard C runtime library is not used, because it's too heavy it
has too many un-needed features/functions. Other parts of the system are
even written in assembly, because of efficiency (more in terms of space than
raw speed ), sure you could write windows HAL's in C, but he! you don't need
any runtime support, all you need to look at is the memory footprint. You
see the closer to the HW the higher the efficiency, every feature comes at a
cost, every additional layer reduces raw-speed and increases the memory
requirements, a great example is the CLR isn't it? But as long as the
features outweight the costs (an acceptable performance) there is nothing
wrong with this high level stuff.

Also note how C data types map directly to hardware: strings are
merely zero-terminated byte sequences, int and long change width
depending on the underlying hardware, floating-point ops may be
unsupported if the underlying hardware doesn't have them. C/C++
aren't called portable assembly languages for no reason. :)

[1] Bjarne Stroustrup: The Design and Evolution of C++, Introduction.
--

http://www.kynosarges.de

Nov 17 '05 #7

P: n/a

"Edward Yang" <ne***********@msn.com> wrote in message
news:eW**************@TK2MSFTNGP11.phx.gbl...
Thanks for your reply. You spent a considerable time on my problem. Thanks
again.
No problem.
What you said is all reasonable. I am that kind of person that sometimes
becomes very critic about something. In this case I really think the C#
language spec is enforcing a useless rule - it's not about practical
things; it's all about theory. C/C++ may have its weakness, which is a
thing I cannot understand. But weakness != uselessness. That's my point.
There is nothing wrong with being skeptic and critical, it's good to tell
the language designerswhat you think about some aspects, even if we are
wrong it might be a great experience.
I guess you are talking about the local variable asignment imposed by the
language compiler, I prefer the way it is done now, I think it's up to the
JIT to optimize it away, but I guess there are other more important things
to optimize right now.

I won't argue with you any more, only with one exception. If C# is going
to have a VB like With/End With construct, it needs only *one* additional
keyword - with, for example:

with(this.control1.collection1[0].property1.subitem1)
{
.name = "Neo";
.age = 99;
}

I know I can use a temporary variable (that is the workaround posted to
the feedback on With/End With construct). But that's NOT what I want - I
want a builtin language construct.

I know what you mean, but you know you can't allways get what you want :-),
I heard some time ago that the language designers could have reserved the
with keyword for a different purpose, don't know what version 3 will bring.
Anyway you can always file a suggestion to productfeedback
(http://lab.msdn.microsoft.com) things might change if there are enough
voters.

BTW, I don't think the number of keywords is a big problem. Yes, C/C++ has
a very small set of keywords, but it also implies a number of
quasi-keywords (or language construct). What is the syntax of pure virutal
methods? You know what I mean.


I think for a language designer it's key to keep an eye on the keyword
count, we don't know how the language may evolve, guess they do.

Willy.
Nov 17 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.