What to do to make compiler consider STATIC Readonly propertiesas CONSTANT?
in [Framework]
|
Prev: What to do to make compiler consider STATIC Readonly properties as CONSTANT?
Next: How does clickonce find the local application?
From: Peter Duniho on 4 Dec 2009 00:59 Leon_Amirreza wrote: > Hi > when i used the following attribute for a property: > 1- [DefaultValue(string.Empty)] > > c# compiler nagged that it expects a constant and forced me to change it > to this > 2- [DefaultValue("")] > > Any1 knows of a better programming style than line No. 2-? No. > I thought compliers exist to encourage better programming practice (that > is more readable, more protable, more writtabe, more maintainable code )? What's wrong with ""? Is there some difficulty understanding what it means? What if the initialization value was a non-empty string? Why is it that "My Non-Empty String" is okay, but "" is not? > Thank god for the reflection for that DotNet compilers can evaluate some > of expressions to constant values at compile time then why doesnt c# do > that? Actually, I hope there's no compiler out there evaluating String.Empty at compile time. It would set a horrible precedent. > I can make many c# examples that compiler needs a constant, while it can > evaluate the expression to a constant, but it doesnt! That's right. Expressions that are not already compile-time literals cannot be proven by the compiler to not change at run-time, and thus should NOT be evaluated for the purpose of declaring a constant. > there are alot of languages for windows and linux (like gnu C++ or any > other variants of C/C++, Embarcadero Delphi - previously Borland Delphi > -, ...) that can not or do not benefit from a platform like DotNet. > As a DotNet Programmer I can benefit from the platform in many ways > (while some drawbacks) but why the compiler itself doesnt benefit from > some of features that already there? The compiler does benefit from features that are already there, at times when it's reasonable to do so. But allowing String.Empty as a compile-time literal isn't one of those times. Pete
From: Marvin Landman on 12 Dec 2009 13:09 Just some thoughts on the problems mentioned below: String.Empty is a field because that can contain an object reference so you will get the same object reference every time you use string.Empty. An empty string constant on the other hand is read form the metadata of the assembly using it. Attribute constructor arguments are serialized (never executed) so you have to use constant values and String.Empty is a field. Compile time code execution would make no sense because the compilation environment can differ from the execution environment. Although readonly fields can actually vary from version to version and implementation to implementation using a property (a special method) call for Environment.NewLine makes sense since that is ment to be platform dependent. If you find that calling an extra methods hurts that much your programs performance, you can store its value in a field or a local variable. Marvin Leon_Amirreza wrote: > What About Environment.NewLine? > it is there for more portable code! any literal exits in c# for that ? > > "Peter Duniho" <no.peted.spam(a)no.nwlink.spam.com> wrote in message > news:eLKGxbKdKHA.6096(a)TK2MSFTNGP02.phx.gbl... >> Leon_Amirreza wrote: >>> Hi >>> when i used the following attribute for a property: >>> 1- [DefaultValue(string.Empty)] >>> >>> c# compiler nagged that it expects a constant and forced me to change >>> it to this >>> 2- [DefaultValue("")] >>> >>> Any1 knows of a better programming style than line No. 2-? >> >> No. >> >>> I thought compliers exist to encourage better programming practice >>> (that is more readable, more protable, more writtabe, more >>> maintainable code )? >> >> What's wrong with ""? Is there some difficulty understanding what it >> means? What if the initialization value was a non-empty string? Why >> is it that "My Non-Empty String" is okay, but "" is not? >> >>> Thank god for the reflection for that DotNet compilers can evaluate >>> some of expressions to constant values at compile time then why >>> doesnt c# do that? >> >> Actually, I hope there's no compiler out there evaluating String.Empty >> at compile time. It would set a horrible precedent. >> >>> I can make many c# examples that compiler needs a constant, while it >>> can evaluate the expression to a constant, but it doesnt! >> >> That's right. Expressions that are not already compile-time literals >> cannot be proven by the compiler to not change at run-time, and thus >> should NOT be evaluated for the purpose of declaring a constant. >> >>> there are alot of languages for windows and linux (like gnu C++ or >>> any other variants of C/C++, Embarcadero Delphi - previously Borland >>> Delphi -, ...) that can not or do not benefit from a platform like >>> DotNet. >>> As a DotNet Programmer I can benefit from the platform in many ways >>> (while some drawbacks) but why the compiler itself doesnt benefit >>> from some of features that already there? >> >> The compiler does benefit from features that are already there, at >> times when it's reasonable to do so. But allowing String.Empty as a >> compile-time literal isn't one of those times. >> >> Pete >
From: Peter Duniho on 12 Dec 2009 18:49 Leon_Amirreza wrote: > What About Environment.NewLine? What about it? > it is there for more portable code! Specifically, because what constitutes a "new line" varies from operating system to operating system (among other things...even on Windows, some programs use only '\n' for a new line, so to some extent it's even more variable than per-platform). > any literal exits in c# for that ? No environment-dependent literal, no. Obviously if you know the context (e.g. HTML), you can always hard-code "\r\n" or "\n" as appropriate. What this has to do with String.Empty, I don't know. String.Empty isn't platform dependent, and always is the same as "". Pete
From: Peter Duniho on 12 Dec 2009 18:54
Leon_Amirreza wrote: > [...] > I guess in IL language it is possible to have somthing that acts like > line NO 1- but only impossible in C#! There's a lot that is supported in IL or the CLR, but which is unavailable from the various .NET languages, including C#. You are free to code in IL if you like. Pete |