|
Fabio Franco wrote: should it?
Yes.
Fabio Franco wrote: my opinion
Doubt it.
Fabio Franco wrote: another filosophical discussion
That's what life is about.
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
I'd like to see the let keyword added to C# for this purpose, to replace var in cases where the binding will not be mutated. Swift makes this distinction, and F# uses let with this meaning (and let mutable for what C# calls var).
It also just feels really good, like a benevolent ruler. The variable wants to have this value, and you just have to let it.
const is what JavaScript uses for non-mutable bindings, but in C# it already specifically refers to compile-time constants in C#. Also, const just doesn't feel as good as letting a variable follow its heart.
|
|
|
|
|
Member 10277807 wrote: I'd like to see the let keyword added to C#
That would actually be pretty cool. It already exists with Linq, but it would a nice addition to the language itself, at least for value types.
let has a functional nature and C# has been slowly adopting some of the functional programming features. I can see it come to C# soon enough.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
I can't do this either 
const DateTime tick = new DateTime(2001, 1, 1);
- Pete
|
|
|
|
|
Of course, you would use readonly for that. I happen to agree with you that const should be allowed in these cases. The readonly verb is an admitted hack by the compiler writers. After all, string is an object (i.e. non-primitive) and you can use const with it.
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
That's because const value must be known at compile-time. Instantiating DateTime requires code execution, which will only be done at run-time.
For that scenario you have the readonly, a run-time constant (intialized once and never changes).
You can only use const on variables that can be represented by literals.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
pherschel wrote: Is it me or do you get confused by this? Why can't I say
const DateTime today = DateTime.Now;
Constants aren't variables, they just look like them, they are aids for the compiler, they don't exist at run-time. When you write
const int x = 5;
int y = 2;
int z = y + x;
bool b = z <= x;
what gets compiled is this
int y = 2;
int z = y + 5;
bool b = z <= 5;
The compiler replaces all instances of "x" with the constant value. If you could define x as DateTime.Now then what would be compiled? If it literally replaced "x" with "DateTime.Now" everywhere it appears then you almost certainly would not get the result you desire. If it replaced DateTime.Now with the date of compilation then that wouldn't work either. What you really want is a read-only variable, and that's why we have read only variables and constants. You have to understand what they are and use them appropriately, that's not a failing of .net.
This is also why you can't make objects const.
const Person p = new Person();
p.FirstName = "John";
p.Age = 33;
Console.WriteLine (p);
pherschel wrote: For properties, why can't I hide the worker variable for the rest of the class?
Use the short-hand version
int PageNbr { get; set; }
Again it's simply a case of understanding the difference and knowing when and where to use the appropriate solution.
pherschel wrote: For destructors, why can't you give me option to destroy right away?
Because .net is better at memory management than you are and if you leave .net to do your memory management you'll get code that performs well, if you try and do your own memory management you get code that performs badly. For one it means the code is harder for the compiler to optimise as the compiler likes to move your code around for the best overall result but when you have in-line memory management you lesser the optimiser's abilities. Also memory deallocation is expensive. If you could free your objects immediately you probably would (otherwise why would you want this feature?) and that will result in a not-insignificant performance hit. By leaving this aspect to .net it can clear the memory down at a time better suited, like when your app is idling, or some other conditions are met. That way the performance hit is not noticeable, it discretely happens in the background.
pherschel wrote: If you open a file and a DB you have to nest usings before you even get started doing some work
You don't have to nest usings at all
using (This x = new This())
using (That y = new That())
{
}
|
|
|
|
|
F-ES Sitecore wrote: Because .net is better at memory management than you are and if you leave .net to do your memory management you'll get code that performs well, if you try and do your own memory management you get code that performs badly.
Well, you could jump outside of the CLR and allocate memory directly such as
unsafe
{
[DllImport(@"C:\Windows\System32\kernal32.dll")
public static extern void * HeapAlloc(void * procHeap, UInt32 dword, UInt32 size);
}Not saying that this is a good thing but it's possible and pretty much defeats the purpose of the CLR and GC. Not to mention memory management is one of the most challenging aspects of computer programing. If it weren't for .Net, my programs would most likely leak memory all over the place (my C and C++ KungFu is not strong).
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
If you need to explain const to someone with a C background: Think of it as a #define. It is integrated in the the language, processed by the compiler rather than a preprocessor, e.g. it is typed, so it isn't a perfect parallell. Yet, lots of the things people think that should be allowed with const can be answered by "Can you do what you want with C #define statements?"
"Constants ain't. Variables won't." - this is what the requests usually boil down to - constants that ain't. (But I can understand that you might be confused by "read-only variables": Considering the semantics, that sounds like an oxymoron, a variable that won't. A more desciptive term would be "set_once", but readonly is firmly established, and can't be changed today.
(In C, you could do it by a #define. I used to do that, e.g. #define ever (;;), so that I could write "for ever { ... }", but some of my colleauges insisted that "while (1) {...}" was far more readable. I suggeste that we declared "#define WW3 0" so that we could write "while (!WW3)", but that was met with even stronger protests.)
|
|
|
|
|
pherschel wrote: How about a free keyword on a variable or something to get me out of the business of resource management
Isn't that a contradiction in terms? Having done over a decade of C++ (and not missing it one bit), it seems to me that if you want a 'free' keyword, then you're not getting out of the business of resource management, you're asking to get into it...
I must be completely misunderstanding something.
|
|
|
|
|
dandy72 wrote: I must be completely misunderstanding something.
Or he is...
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
I always give the other guy the benefit of the doubt. Then if it turns out I'm right, I point and laugh.
|
|
|
|
|
In my historical archives I have preserved a long NetNews-discussion from the late 1990s: Even that late, there were some people insisting that high level languages are just a short-lived fad; programmers will soonrealize that for high-performing programs, you must code in assembler. Fortunately, they were not right.
For another fifteen years, I was similarly convinced that to control memory use, you simply had to do mallocs and frees yourself in longhand. No way can an automatic garbage collector know what is the best strategy. Then I read the memory management chapter of "CLR via C#". Again and again, I said to myself: Gee, that's smart! I would never have thought of that! ... So my sceptisism towards garbage collectors dwindled away in a few days.
I have several colleagues who have not yet read the same book, so they are still as sceptical as I used to be. Besides, some of them are coding in C rather than C#. If/when you switch from C to C#, you might want to bring some old habits over to the new environment, such as trying to "help" the GC. You should not. Its usefulness is at the same level as telling the C compiler how to use its registers. (I recently read that 'register' will disappear from C++17 - I'd say that is extremely overdue.)
|
|
|
|
|
Member 7989122 wrote: If/when you switch from C to C#, you might want to bring some old habits over to the new environment, such as trying to "help" the GC. You should not.
Well said. When I transitioned from C++ to C#, I read a small amount of material on garbage collection (admittedly, a very small amount), but everything I read convinced me from the get-go that it was pointless to try to do just that, and instead just let it do its job. I've never looked back.
|
|
|
|
|
What's so wrong with it?
If you don't like the idea, you could always just:
var someObject = new MyDisposableObject();
someObject.Dispose();
The trouble with that is, if the code never reaches that Dispose line, it won't get called. In which case you then incorporate it into a try-finally block like so:
var someObject = new MyDisposableObject();
try {
}
finally {
someObject.Dispose();
}
But ... that's exactly what a using clause does for you ... just a whole lot less coding on your side:
using (var someObject = new MyDisposableObject()) {
}
I might have liked an idea where you could add numerous unrelated disposables into the using clause - this may alleviate nesting usings. Though take note that with nesting you've got some control over the order in which they're disposed. Also some disposables are contained in other disposables, and in most such cases disposing the container does so to its contents as well, meaning you only need dispose the final container --> only one using clause.
More of an issue for me is the fact that a destructor isn't called deterministically, if at all. If such were possible, then the dispose pattern could be moved into the destructor instead of a dispose method. And even if you forget to dispose it, it would finally happen once the GC frees it from resources. Though this means the entire GC idea needs a revamp, in fact some of C#'s creators also think this is one of the biggest mistakes in the entire DotNet, just that they do know the reasons such choice was made.
|
|
|
|
|
From your example (i.e. placing DateTime.Now into a const) ... are you intending to save the compile timestamp into the executable code? What would be the intent? It would be pretty close (if not exactly the same) as the file date of the EXE/DLL.
Only idea I could think for this to be used is to check if the executing file has been altered since it was compiled. Though for that I'd rather use some hash value instead, even just CRC would be more comprehensive than a timestamp.
To me, the readonly idea makes more sense - i.e. it would save the time the program was started.
This is the true difference between const and readonly: Const is as if the compiler changes your code to as if you typed in a literal value. Readonly is a way to make sure a variable only gets assigned its value once - from any calculation at runtime. The two ideas are not interchangeable, at least not in most cases.
|
|
|
|
|
These are probably a good idea. Though semantic-wise I'd actually want it to be a readonly instead. In C++ const is used to give the compiler a hint so it knows this parameter wont get changed inside the function, so a copy of it need not go onto its stack (just a direct memory link instead). But even there I'd actually want to rename it to something like readonly instead, const just confuses the hell out of me (is it only a param calculated at compile time, why then not just a normal const in the first place and do away with the param entirely?)
|
|
|
|
|
Here you may be onto something. I'd imagine getting something like this working at present would be a form of making automatic struct types for each property - incorporating their default properties with a get set as defined in code. Perhaps including it into the spec could be done more efficiently.
It should definitely not be enforced though. In some cases the rest of the class does need to see the underlying data without needing to go through the accessor methods. Which in turn brings up another issue in C# ... the inability to have default properties like you can in VB-Net. In C# your closest match is to make implicit type-casting operator overloads.
|
|
|
|
|
I thought this was the lounge?? 
|
|
|
|
|
iOS 11 can automatically delete apps to save space - The Verge[^]
Quote: the Offload feature removes little-used apps, but keeps their documents and data on your device.
Will this really save much space? Do you have many apps that are big in file size? It doesn't seem like it would help much.
Why is storage space still an issue in 2017?
There are two kinds of people in the world: those who can extrapolate from incomplete data.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
RyanDev wrote: Why is storage space still an issue in 2017?
Because their market segmentation strategy uses storage size as a way to scam people out of a disproportionate amount of money .. which makes it even stranger that they want to save space, if anything they should want to waste it.
|
|
|
|
|
Apps likely not the real issue, more likely iOS's own bloat. And to be fair it's a pattern of all OS's.
These days "updates" tend to be as large (sometimes even larger) than the original and always need a ton of temp space to install whatever storage you have will always be a premium.
Sin tack
the any key okay
|
|
|
|
|
Lopatir wrote: to install whatever storage you have will always be a premium.
It's only a premium when storage space is running low. Why is storage space such an issue these days? The capacity to make bigger and larger storage is there.
There are two kinds of people in the world: those who can extrapolate from incomplete data.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
Quote: especially those saddled with just 16GB of storage.
Whoever will need more than 64 KB of memory?
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
Forogar wrote: Whoever will need more than 64K Bit of memory?
FTFY!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
