|
Somehow Rockit makes me think of this[^] 
|
|
|
|
|
Not sure what that is -- maybe an Aussie product?? -- and I'm afraid to ask. 
|
|
|
|
|
Maybe you are too young to know about this, every housewife in the sixties used it (in the Netherlands at least)
(and no, it's not a drug)
|
|
|
|
|
|
See Richard's answer, he's ancient too
|
|
|
|
|
No, it was common in the UK as well. Throw a bag into the laundry and it adds a bleaching agent.
|
|
|
|
|
Since I'm moving to VS2022, I've decided to reorganise my (rather chaotic) library and utility code base: some of it is still building for x86 in a 64 bit world, and there are a lot of possible DLL's / projects to include in new project reference.
So I've set aside a couple of days to reorganise it all into four Solutions:
Templates (for VS templates as I have to regenerate them each time I move to a new version, and I use half a dozen or so)
Utility Code (which is generic and doesn't interact with DB's, Displays, etc).
Utility Controls
Utility Applications
So, I create my first Template project - a Class Library with my default Regions added, an automatic Timestamp, and (later) the standard references to the Utility Code. Based on teh VS Class Library template.
Compile, it's fine. Export as a template, work around MS lies, get it recognised as a template I can use in a C\ app.
Create the new Utility Code project, using the "Class Library with Regions" template.
Add the first CS file from the previous layout.
Add the second ... Wait a minute ... what are those red lines?
Who the ![Elephant | [mastadon]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/elephant.gif) decided that reference types would default to non-nullable in C# 8.0?
That's a breaking change you halfwit! 
Massive sections of my code no longer compile any more due to this stupidity.
I see what you were trying to do, but making it a breaking change is just moronic - and means I have to disable iot globally and slowly work my way into it - particularly as many default method parameters use null.
"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!
|
|
|
|
|
|
Yep, as he said you can set an option.
Yep, it's a breaking (unbreaking by config) change.
Their heart is certainly in the right place in trying to catch issues as you code.
I can't think of a better way to go about it and they DID us notice a starting a couple of releases back that it was coming.
I know that doesn't help your brief WTF shock. 
As someone further on said, a reasonable idea and leads to less breakable code and the fix isn't tough in the singular instance, but it depends on how many instances you have how big of a task to make the changes.
Good luck!
|
|
|
|
|
You created your own template - so can't you just disable nullable in that template? Or is there something I missed?
As it will be very hard to find a reason to not enable nullable for a new code base, I agree with Microsoft it should be the default in new projects.
|
|
|
|
|
I agree that it is intrusive to an older code-base to force this change.
It seems crazy that you'll now have work to do when all you are doing is upgrading to newer version & (re)compiling.
In this case, you knew that reference types were nullable and handled them properly.
Is there just a flag to set in the project somewhere?
|
|
|
|
|
You can tell it not to check, but that's just delaying the problem - and potentially causing more confusion if someone reuses the code for a similar purpose and it then throws up (pretty much incomprehensible) errors on identical code ...
And I suspect it'll be worse for "newer coders" since they all seem to use var exclusively instead of explicit typing, so the actual type of a variable will change and throw up yet more errors later on ...
"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!
|
|
|
|
|
var should be banished to the depths of time! If you can't explicitly type the variable then you obviously don't understand the problem.
|
|
|
|
|
var is like auto in C++, right? I use it wherever possible. I know what the type is. If the reader doesn't, they need to learn so that they'll truly understand the code. 
|
|
|
|
|
So,
Greg Utas wrote: auto in C++, right? I use it wherever possible. I know what the type is. If the reader doesn't, they need to learn so that they'll truly understand the code.
You hide your variable types behind the auto keyword and have an elevated THREAD_PRIORITY_HIGHEST thread in all your multi-threaded processes.
Any other tips you want to share? It just keeps getting better.
|
|
|
|
|
|
Yep,
I'd like to get your opinion on something. Would you be willing to do that?
How does the auto keyword impact the reliability, debuggability and robustness of C++ code?
|
|
|
|
|
I'm always willing to play the straight man!
The main problem with auto is that the type ends up being something that you need to consider more carefully:
for(auto i = container.size() - 1; i >= 0; --i)... and you've got an infinite loop because i is unsigned. I've been burned by this a few times, so have learned to write int instead of auto here. But that overrides the type; "correctly" saying size_t would cause the same problem.
|
|
|
|
|
Thanks,
I'm still learning the ropes. But I do enjoy hanging out with you guys in the Lounge. ![Rose | [Rose]](https://www.codeproject.com/script/Forums/Images/rose.gif)
|
|
|
|
|
Awesome to see such productive back and forth comments. Seemed to border on getting offtrack, but was rescued at the last moment. Great work guys!
|
|
|
|
|
Nah,
I was twisting the dagger down to the last letter[^]. I just wrote it using double entendre so that only a poet could know it.
I like Greg, this is just my unique way of showing it. I think he can handle it.
|
|
|
|
|
I'm probably missing a joke or 2 here, but I'm having a hard time seeing the benefit of auto-typing.
Since you 100%, always, with 0 possible exceptions know the complete type when you're writing the code..
Why would you want to obscure it?
It's like having both a pig, and some lipstick, and feeling compelled to apply the latter to the former just because you can.
|
|
|
|
|
When using templates in C++, the type can be a mess, so it looks like a pig. Using auto also lets me keep lines to 80 characters while rarely having to spill them. So the pig disappears, and all that's left is the lipstick. Call it the Cheshire Pig!
|
|
|
|
|
I'd be more likely to use an iterator for that case. Besides, doesn't the compiler generate a warning/error? It should know that testing an unsigned against all positive integers always returns true and seems common enough for them to catch it.
Where Auto/Var shine for me is that it's more readable in the more normal SomeObject object = new SomeObject(Parameters) case.
|
|
|
|
|
I usually use an iterator for that too but wanted to come up with an example quickly. And you're right that the compiler will probably give a warning.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
