Whose idea was this in C\?
-
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: decided that reference types would default to non-nullable in C# 8.0? That's a breaking change you halfwit! :mad: 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!
-
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: decided that reference types would default to non-nullable in C# 8.0? That's a breaking change you halfwit! :mad: 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!
I looks like they put some thought into this. You may need to make some settings changes, etc. Nullable reference types | Microsoft Docs[^]
-
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: decided that reference types would default to non-nullable in C# 8.0? That's a breaking change you halfwit! :mad: 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!
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.
-
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: decided that reference types would default to non-nullable in C# 8.0? That's a breaking change you halfwit! :mad: 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!
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?
-
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
varexclusively 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!
-
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
varexclusively 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.
varis likeautoin 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. :-DRobust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
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.
We use
varall the time at our shop, where applicable. -
varis likeautoin 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. :-DRobust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.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
autokeyword and have an elevatedTHREAD_PRIORITY_HIGHESTthread in all your multi-threaded processes. Any other tips you want to share? It just keeps getting better. -
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
autokeyword and have an elevatedTHREAD_PRIORITY_HIGHESTthread in all your multi-threaded processes. Any other tips you want to share? It just keeps getting better.The type is on the RHS.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
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
varexclusively 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!
I used to explicitly type all my variables until recently when it seems to have become fashionable in my department to use
var. I don't normally follow coding fashions unless they make sense, and this sure makes the code look cleaner. And as long as IntelliSense knows what type it is and shows me the correct properties and methods, I'm happy.If you think 'goto' is evil, try writing an Assembly program without JMP.
-
The type is on the RHS.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
Yep, I'd like to get your opinion on something. Would you be willing to do that? How does the
autokeyword impact the reliability, debuggability and robustness of C++ code?I'm always willing to play the straight man! The main problem with
autois 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
iis unsigned. I've been burned by this a few times, so have learned to writeintinstead ofautohere. But that overrides the type; "correctly" sayingsize_twould cause the same problem.Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
I'm always willing to play the straight man! The main problem with
autois 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
iis unsigned. I've been burned by this a few times, so have learned to writeintinstead ofautohere. But that overrides the type; "correctly" sayingsize_twould cause the same problem.Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
Thanks, I'm still learning the ropes. But I do enjoy hanging out with you guys in the Lounge. :rose:
-
varis likeautoin 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. :-DRobust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.Quote:
var is like auto in C++, right?
I used to think that. But I am not so sure anymore in terms of the net effect in each language. In our C# code, I demand that the type be determinable by reading the line the type is defined on. I.e. if a variable is initialized by a value returned from a method, you best not use var. The reasoning is not that a developer can't determine the type with enough effort. It is the time it takes someone reading the code to KNOW what the code is doing and meant to do. At the end of the day it is about developer productivity. Experienced developers aren't questioning if they can make something work or focusing on the time it takes to key in their code. It is how effective they are at solving problems and maintaining volumes of code. Using var is optimizing the writing of code at the expense of the total cost of the code over the life of the code. But, when moving over to C++ and understanding the design best practice of (Always Use Auto), I had to step back and evaluate why someone would recommend a coding pattern that made code take longer to understand and would drop developer productivity. In the end, I came to the conclusion that the C# patterns that we tend to use don't use structs, almost always use classes, and as a result, put the memory on the heap. In these scenarios there is no runtime benefit the compiler can help you with that makes your code more effective since all non primitive variables are just references. var only gives an opportunity to save time typing code at the expense of maintaining it. C++ on the other hand appears to prefer patterns where local variables do not use the heap and the compiler is both optimizing the implicit type conversion and if it can use a reference instead of a copy with every variable use. In the patterns I am aware of, it is minimizing the copying of data and the running of class move/copy/ctor/dtor methods for you. Without using auto here, the compiler's hands have been tied. All of that being said, I would like the input of those who have written a lot of modern C++ to see if I am missing anything. I also believe that if our C# code used structs that had implicit type conversions more, the reasoning of not allowing var may be misguided. Although I have not pulled on this thread and do not know much about the C# compiler optimization in these cases.
-
Quote:
var is like auto in C++, right?
I used to think that. But I am not so sure anymore in terms of the net effect in each language. In our C# code, I demand that the type be determinable by reading the line the type is defined on. I.e. if a variable is initialized by a value returned from a method, you best not use var. The reasoning is not that a developer can't determine the type with enough effort. It is the time it takes someone reading the code to KNOW what the code is doing and meant to do. At the end of the day it is about developer productivity. Experienced developers aren't questioning if they can make something work or focusing on the time it takes to key in their code. It is how effective they are at solving problems and maintaining volumes of code. Using var is optimizing the writing of code at the expense of the total cost of the code over the life of the code. But, when moving over to C++ and understanding the design best practice of (Always Use Auto), I had to step back and evaluate why someone would recommend a coding pattern that made code take longer to understand and would drop developer productivity. In the end, I came to the conclusion that the C# patterns that we tend to use don't use structs, almost always use classes, and as a result, put the memory on the heap. In these scenarios there is no runtime benefit the compiler can help you with that makes your code more effective since all non primitive variables are just references. var only gives an opportunity to save time typing code at the expense of maintaining it. C++ on the other hand appears to prefer patterns where local variables do not use the heap and the compiler is both optimizing the implicit type conversion and if it can use a reference instead of a copy with every variable use. In the patterns I am aware of, it is minimizing the copying of data and the running of class move/copy/ctor/dtor methods for you. Without using auto here, the compiler's hands have been tied. All of that being said, I would like the input of those who have written a lot of modern C++ to see if I am missing anything. I also believe that if our C# code used structs that had implicit type conversions more, the reasoning of not allowing var may be misguided. Although I have not pulled on this thread and do not know much about the C# compiler optimization in these cases.
I'm unaware of any way that
autohelps to produce more efficient code. If you don't want a deep copy, you have to writeauto& id =.... And if it'sconst, you have to writeconst auto id =.... Yes, Herb Sutter wrote an article "Almost Always Auto (AAA)." As far as someone reading the code having to look up the type returned by a function goes, my take is that knowing the type is only the first step to understanding. The reader also needs to know the function's purpose, which means reading its interface documentation. And given that we sometimes fall short on that front, it can also mean reading its implementation. Providing the type can therefore be detrimental by giving a false sense of security. Although I haven't used C#, I'd be surprised if best practices for when to use the heap versus the stack weren't the same in both languages.Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
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: decided that reference types would default to non-nullable in C# 8.0? That's a breaking change you halfwit! :mad: 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!
Did I ever mention why I hated MSFT? and most of their products? THIS. Exactly This! The last straw was when they stopped adding changes to the 16 Bit C/C++ compiler that they were putting into the 32 bit version. Our lead dev made a 32 bit library that we were forced to write a Thunking layer to use. He used almost every new feature he could. In the end, I forcibly recompiled the code using a Borland 16 bit compiler. The ONE thing I LIKED about Oracle was that for DECADES we would simply DUMP our DB and Code. Import it into a newer version, and it worked. Hundreds of upgrades, and we barely ever ran into something that no longer compiled. Something I can honestly say NEVER happened with MSFT stuff. From VB breaking every version, to the above, to MSSQL T-SQL changes. (Heck, SqlCmd has a :Connect command. Try to use it in Azure hosting! Because it does NOT support choosing the Database. So it fails. It's as if ONE HAND has no idea what the other is doing). Good ideas are great... But going in to make a small change to a system, and finding out you cannot even begin to recompile it because of the new compiler. Imagine if Linux was built on those precepts! I feel your pain!
-
I'm always willing to play the straight man! The main problem with
autois 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
iis unsigned. I've been burned by this a few times, so have learned to writeintinstead ofautohere. But that overrides the type; "correctly" sayingsize_twould cause the same problem.Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.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. :rose:
-
Quote:
var is like auto in C++, right?
I used to think that. But I am not so sure anymore in terms of the net effect in each language. In our C# code, I demand that the type be determinable by reading the line the type is defined on. I.e. if a variable is initialized by a value returned from a method, you best not use var. The reasoning is not that a developer can't determine the type with enough effort. It is the time it takes someone reading the code to KNOW what the code is doing and meant to do. At the end of the day it is about developer productivity. Experienced developers aren't questioning if they can make something work or focusing on the time it takes to key in their code. It is how effective they are at solving problems and maintaining volumes of code. Using var is optimizing the writing of code at the expense of the total cost of the code over the life of the code. But, when moving over to C++ and understanding the design best practice of (Always Use Auto), I had to step back and evaluate why someone would recommend a coding pattern that made code take longer to understand and would drop developer productivity. In the end, I came to the conclusion that the C# patterns that we tend to use don't use structs, almost always use classes, and as a result, put the memory on the heap. In these scenarios there is no runtime benefit the compiler can help you with that makes your code more effective since all non primitive variables are just references. var only gives an opportunity to save time typing code at the expense of maintaining it. C++ on the other hand appears to prefer patterns where local variables do not use the heap and the compiler is both optimizing the implicit type conversion and if it can use a reference instead of a copy with every variable use. In the patterns I am aware of, it is minimizing the copying of data and the running of class move/copy/ctor/dtor methods for you. Without using auto here, the compiler's hands have been tied. All of that being said, I would like the input of those who have written a lot of modern C++ to see if I am missing anything. I also believe that if our C# code used structs that had implicit type conversions more, the reasoning of not allowing var may be misguided. Although I have not pulled on this thread and do not know much about the C# compiler optimization in these cases.
At the end of the day, it's still sacrificing ease of maintenance for better CPU performance. No matter how you slice it, that's not a trade-off I'm comfortable with, given the average amount of defects per KLoC in C++ code. Then again, I avoid writing C++ for specifically that reason. (that and my hate for having to maintain and patch a couple of C++ projects that have long been abandoned by their creators)
