|
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!
|
|
|
|
|
Nobody. I always forget the useless bits.
... such stuff as dreams are made on
|
|
|
|
|
RyanDev wrote: Will this really save much space? Do you have many apps that are big in file size?
Absolutely. Maps can be well into the Gb size, as can graphics/asset heavy games.
It's also not about individual size: if you happen to be a hoarder then 100 apps each at 100Mb will be 10Gb, right? That's harsh if you've only been able to afford a 16Gb version of the phone.
cheers
Chris Maunder
|
|
|
|
|
Chris Maunder wrote: Maps can be well into the Gb size
But I wonder if the OS will consider the maps to be data and leave them behind, assuming they are separate resource files and not embedded.
Chris Maunder wrote: then 100 apps each at 100Mb
I don't even have one app that comes close to 100 MB. I guess I'm doing it wrong.
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: But I wonder if the OS will consider the maps to be data and leave them behind
I'm sure everything would be backed up to iCloud. For a small administrative fee, of course.
RyanDev wrote: I don't even have one app that comes close to 100 MB
You're lucky. Over half my apps are over 100Mb. Just getting over that line are things like The Weather Network App (seriously: it just needs to display info from a webservice!) and our local parking meter app. 101Mb to pay for my parking. Crazy considering Outlook is "merely" 106Mb.
cheers
Chris Maunder
|
|
|
|
|
Chris Maunder wrote: I'm sure everything would be backed up to shared into the iCloud. For a small administrative feeDue to the next security leak / hack, of course.
FTFY
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
RyanDev wrote: Why is storage space still an issue in 2017?
It's only an issue when your phone doesn't have a MicroSD slot.
|
|
|
|
|
dandy72 wrote: It's only an issue when your phone doesn't have a MicroSD slot.
Is that one of those items iPhones leave out?
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.
|
|
|
|
|
My understanding (as someone who's never owned one, and never will) is that yes, not a single iPhone has ever included a MicroSD slot. Meaning that if you're afraid you're gonna run out of room one day, you're gonna spend more upfront to get the larger-capacity one.
It's a feature. For Apple.
|
|
|
|
|
dandy72 wrote: It's a feature. For Apple.
And people complain about how Microsoft treats them.  Interesting.
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
