473,327 Members | 2,055 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,327 software developers and data experts.

Verifiable methods and C# language rule about local variable

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

"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

"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

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

"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

"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 thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

5
by: Arnd Baecker | last post by:
Hi, the summary of my question is: is there a way to append commands to a method inherited from another class? More verbose: Assume the following situation that I have a class class_A with...
27
by: gabor | last post by:
hi, as far as i know in python there aren't any private (i mean not accessible from the outside of the object) methods/fields. why? in java/c++ i can make a method private, this way...
16
by: Michele Simionato | last post by:
I have read with interest the recent thread about closures. The funny thing is that the authors are arguing one against the other but I actually agree with all of them and I have a proposal that...
99
by: David MacQuigg | last post by:
I'm not getting any feedback on the most important benefit in my proposed "Ideas for Python 3" thread - the unification of methods and functions. Perhaps it was buried among too many other less...
0
by: Anthony Baxter | last post by:
To go along with the 2.4a3 release, here's an updated version of the decorator PEP. It describes the state of decorators as they are in 2.4a3. PEP: 318 Title: Decorators for Functions and...
0
by: Edward Yang | last post by:
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...
9
by: zholthran | last post by:
Hi folks, after reading several threads on this issue (-> subject) I fear that I got a problem that cannot easily be solved by the offered workarounds in an acceptable way, at least not with my...
3
by: rickeringill | last post by:
Hi comp.lang.javascript, I'm throwing this in for discussion. First up I don't claim to be any sort of authority on the ecmascript language spec - in fact I'm a relative newb to these more...
2
by: Jon Slaughter | last post by:
I was wondering if maybe allowing "fields" for methods. The reason is to encapsulate the data that is mainly used by the method and to prevent the need of having to create new variables every time...
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
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: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
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: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
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...
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...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

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.