|
Snow is perfectly fine when the snow is dry, it is five to ten degrees below freezing and staying there!
The terrible conditions are when it temperature swings around freezing all the time - slush, ice, ice cold rain ... Zero is actually a lot colder than ten below! Besides, when it "warms" up, the winds come.
I'd much rather take a calm day with the sun shining from a deep blue sky at twenty to twentyfive degrees below zero, and dry snow plowed two meters high, than slushy streets with cars spraying all over you, and the ice cold rain is going right into your bones at two degrees plus.
|
|
|
|
|
One reason I left that part of NY when I graduated high school. (A dying economy being the main reason.)
|
|
|
|
|
I'm having one of those mornings where I try and catch up on new features they've stuck in C# and .NET. I have to say I don't always like what I read, maybe I'm a coding language Conservative or something, but I do sometimes come around to new features about five years late.
Nullable reference types (they're nullable already surely?) (Embracing nullable reference types | .NET Blog) is one such example that when I first heard about it a year or two ago I thought it so preposterous that I would never activate it, and sure enough there are no ?s at the end of my strings to date. Now do I dig in or accept change?
A null reference, well a null pointer, ultimately a bad address in memory just seems to me an inherent trap with computers. I first did it 40 years ago on a Commodore VIC20 before they had invented exceptions, the thing would just go mental until you switched it off. And every day since for that matter but usually by production such errors are gone. In development they're a good pointer (hey, a pun!) to where things aren't quite right yet.
I like things the way they are (were). How do you like nullable reference types?
Regards,
Rob Philpott.
|
|
|
|
|
Rob Philpott wrote: How do you like nullable reference types?
If this is a valid answer for you... So far I haven't used them (yet?)
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.
|
|
|
|
|
Perfectly valid. I like it too!
Regards,
Rob Philpott.
|
|
|
|
|
That's a difficult one.
I haven't started using them, but I suspect I probably should on the basis that the more errors I can catch at compile time rather than run time means less errors I have to specifically test for or code to handle.
I can't help the feeling that there are too many C++ and VB fanboise trying to get the nastier bits of of their original code into the C# spec though: var without Linq, dynamic, and so on does kinda dumb down the language without adding any benefit in the real world.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: I haven't started using them, but I suspect I probably should on the basis that the more errors I can catch at compile time rather than run time means less errors I have to specifically test for or code to handle.
That's actually a really good point. Thanks
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.
|
|
|
|
|
Yes it seems var, Brexit and Covid lockdowns are the divisive issues of our times.
I'd venture that the young probably are more advocates of var, particularly if they've come from some horrible dynamic language. But those of us who went through the OO revolution in the 90s and had the 'type is everything' mantra drummed into us just find it obscures things.
I don't mind dynamic, but there has to be a very good reason for it!
Regards,
Rob Philpott.
|
|
|
|
|
var and dynamic languages have nothing in common. If anything, var is coming from functional languages with stronger type safety than C# and which won't let you do it any other way 
|
|
|
|
|
I don't think var dumbs down the language any more than auto dumbs down C++. You may not like it, but it saves *typing* not *thinking*, IMO.
Besides, in C# due to lack of a reasonable alternative to typedef it's par for the course, LINQ or no - if you're using a lot of generics.
Real programmers use butterflies
|
|
|
|
|
One of the few features I was really looking forward to. And I am happy with it.
Null is very often a special case - and now I can clearly express in the code if this special case is something that needs to be delt with, or something that will not happen. Meaning guard code is in added where it is needed, and not filling up the code where doesn't do anything.
Why you would not want the compiler to help identifying inherit traps is something I just don't understand. Maybe because I never had to struggle with assembly on the VIC20 - I was one of those modern kids that did assembly on the C64.
|
|
|
|
|
lmoelleb wrote: Why you would not want the compiler to help identifying inherit traps is something I just don't understand.
That's a strong argument. Compile time errors have to beat runtime. But I guess I'm just very relaxed about things being null. It's a useful paradigm for 'there isn't one' etc. Reading from a StreamReader for instance gives you a null at the end of the stream, perfect condition on the loop. But then I guess the argument is that it should be a string?
How are they going to do away with the divide by zeros? That's what I want to know!
Regards,
Rob Philpott.
|
|
|
|
|
No one is arguing against null being a useful paradigm. And now we have the syntax to tell if the paradigm is used or not.
This serves two purposes:
1) Communicate intent. You can see from the type of my method if you need to handle a null being returned. You can see by the parameter definition if my code can handle a null being passed in.
2) Compiler can catch more mistakes.
Either of these would be more than enough for me to use nullable - with both of these... don't get why you would not use it on any new code. Legacy code is of course always an issue... when to (and if) make the investment to change it.
|
|
|
|
|
I have to say your starting to convince me, this is hard to argue with. I think I might try it out later on and see how it feels..
Regards,
Rob Philpott.
|
|
|
|
|
Coming from a C++ background, I would say that the whole point of references (as opposed to pointers) is that a reference can never be null; nullable references are a fundamental violation of the programming model.
If you want pointers, why not use C++?
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Daniel Pfeffer wrote: If you want pointers, why not use C++?
Because of header files, and 20 years of .NET has made me too stupid in general.
Regards,
Rob Philpott.
|
|
|
|
|
To be aware of it is the first step 
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.
|
|
|
|
|
I recently came back home to C++ from years long C# development. I'm a bit rusty, but it's coming back. You may surprise yourself if you give it another go. *hides*
Real programmers use butterflies
|
|
|
|
|
Daniel Pfeffer wrote: a reference can never be null
They're not supposed to be null, but they can be. If someone passes *ptr as an argument, and ptr is nullptr, defensive code still has to include if(&ref == nullptr).
modified 16-Dec-20 9:06am.
|
|
|
|
|
Dereferencing a nullptr is already undefined behaviour. You have already "broken the machine" before making the call, so anything that happens now - including termination of the program - is possible.
Because the machine is broken, defensive programming is the wrong answer. You should use methods outside the C++ model (e.g. Windows Structured Exception Handling) in order to restart the program from a known OK point, or abort gracefully with an intelligible message to the user.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
It's not undefined behavior yet. Almost every compiler just passes the unchecked nullptr reference to the called function, which goes off the cliff if it uses the member selection operator. The called function can therefore protect itself in the way described, and fail gracefully if it wishes.
|
|
|
|
|
Greg Utas wrote: It's not undefined behavior yet.
It is:
A reference shall be initialized to refer to a valid object or function. [Note: in particular, a null reference cannot exist in a well-defined program, because the only way to create such a reference would be to bind it to the “object” obtained by dereferencing a null pointer, which causes undefined behavior. As described in 9.6, a reference cannot be bound directly to a bit-field.]
Just because it works today on your set of compilers, does not mean it will continue to work tomorrow when for instance standard introduce contracts or compiler implementer decide to make optimizations based on the assumption. Compilers are already taking UB as license to do optimizations, giving language users all kind of WTF moments.
Most famous case of a similar nature is probably this one in Linux: Fun with NULL pointers, part 1 [LWN.net]
The point is you cannot reason about UB.
|
|
|
|
|
I agree that the naughty code should be trapped, but most compilers are also naughty.
|
|
|
|
|
|
That's execrable if they're not trapping null references.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
