WTF (.NET?)
-
I'm fine with single scope operators like a::foo(); MSXML2::IXMLDOMNodePtr pNode=NULL; MSXML2::IXMLDOMNodeListPtr pNodeList=NULL; I guess my issue is with how deep this .NET stuff gets in terms of levels in... System.Windows.Forms.DialogResult.OK Thats just excessive and overkill. The "DialogResult.OK" is potentially defined elsewhere making it an ambiguous symbol potentially in larger apps. "Using" the namespace is not really a good all around solution except in the classroom.
-- modified at 14:18 Saturday 22nd July, 2006
"Using namespace" was considered bad when C++ was popular, but those times are long gone. "Using namespace" is the right and popular thing now and encouraged by any "Add something" wizard in Visual Studio.
Best regards, ----------- Igor Sukhovhttp://sukhov.net
-- modified at 12:02 Saturday 22nd July, 2006
-
"Using namespace" was considered bad when C++ was popular, but those times are long gone. "Using namespace" is the right and popular thing now and encouraged by any "Add something" wizard in Visual Studio.
Best regards, ----------- Igor Sukhovhttp://sukhov.net
-- modified at 12:02 Saturday 22nd July, 2006
-
"Using namespace" was considered bad when C++ was popular, but those times are long gone. "Using namespace" is the right and popular thing now and encouraged by any "Add something" wizard in Visual Studio.
Best regards, ----------- Igor Sukhovhttp://sukhov.net
-- modified at 12:02 Saturday 22nd July, 2006
As far as house rule goes "Using namespace" in a header is off limits, but not in a cpp
Some of us walk the memory lane, others plummet into a rabbit hole
Tree in C# || Fold With Us! || sighist -
I'm fine with single scope operators like a::foo(); MSXML2::IXMLDOMNodePtr pNode=NULL; MSXML2::IXMLDOMNodeListPtr pNodeList=NULL; I guess my issue is with how deep this .NET stuff gets in terms of levels in... System.Windows.Forms.DialogResult.OK Thats just excessive and overkill. The "DialogResult.OK" is potentially defined elsewhere making it an ambiguous symbol potentially in larger apps. "Using" the namespace is not really a good all around solution except in the classroom.
-- modified at 14:18 Saturday 22nd July, 2006
bob16972 wrote:
The "OK" is potentially defined elsewhere making it an ambiguous symbol potentially in larger apps.
Even when using the using statement you will have to write
DialogResult.OKnot onlyOK. Thus the chance of an ambiguouty is rather small. Robert -
bob16972 wrote:
The "OK" is potentially defined elsewhere making it an ambiguous symbol potentially in larger apps.
Even when using the using statement you will have to write
DialogResult.OKnot onlyOK. Thus the chance of an ambiguouty is rather small. RobertI had already changed that once, but apparently my "modify" did not stick. I saw a comment like yours coming right after I originally posted it so I thought Id modify it but technology apparently failed me. I went ahead and re-clarified it. The "DialogResult.OK" could potentially be valid in other namespaces so my statement should bear some weight. For what it's worth...
-
I had already changed that once, but apparently my "modify" did not stick. I saw a comment like yours coming right after I originally posted it so I thought Id modify it but technology apparently failed me. I went ahead and re-clarified it. The "DialogResult.OK" could potentially be valid in other namespaces so my statement should bear some weight. For what it's worth...
-
I was just casually strolling through VB'land and came across a question that had a snippet with this in it... If Result = System.Windows.Forms.DialogResult.OK Then I'm not a .NET person so forgive my inexperienced eyes, but are they really serious? That's quite long winded for something so trivial and probably common place. It makes me embrace my simple native loving VC++ 6.0 even tighter. This is a sad world indeed if that's progress. We are just asking for a repetitive motion injury with coding like that!
The bit I don't get is why they have to store the result. The preceding line is almost certainly Dim Result as System.Windows.Forms.DialogResult = myForm.ShowDialog() Given that System.Windows.Forms is scope automatically anyhow, the code should look like this: if myForms.ShowDialog = DialogResult.OK Then
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
-
The bit I don't get is why they have to store the result. The preceding line is almost certainly Dim Result as System.Windows.Forms.DialogResult = myForm.ShowDialog() Given that System.Windows.Forms is scope automatically anyhow, the code should look like this: if myForms.ShowDialog = DialogResult.OK Then
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
Christian Graus wrote:
Given that System.Windows.Forms is scope automatically anyhow, the code should look like this: if myForms.ShowDialog = DialogResult.OK Then
Automatic due to a Koenig-like lookup, or because the wizard has injected a using System.Windows.Forms line somewhere in the file? If the former, then :cool:
-- From the Makers of Futurama
-
Christian Graus wrote:
Given that System.Windows.Forms is scope automatically anyhow, the code should look like this: if myForms.ShowDialog = DialogResult.OK Then
Automatic due to a Koenig-like lookup, or because the wizard has injected a using System.Windows.Forms line somewhere in the file? If the former, then :cool:
-- From the Makers of Futurama
Latter, I am afraid. In C#, you also can't put a using statement for a single object in a namespace, AFAIK you can't do the equivelant of using std::cout;
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
-
"using" directives can cause name clashing, can they not?
-- modified at 12:33 Saturday 22nd July, 2006 How exactly is someone reading the code supposed to know which namespace something is from? If you have 25 "using" statements, they are going to have a hard time tracking down which class to look up in MSDN to understand it's usage later on when somebody else is maintaining your code. Am I missing something?
bob16972 wrote:
"using" directives can cause name clashing, can they not?
Yes, but it's rare. The convenience of not having to always fully qualify type names far outweighs the possibility of name collisions. If a collision occurs, the compiler will let you know.
bob16972 wrote:
How exactly is someone reading the code supposed to know which namespace something is from? If you have 25 "using" statements, they are going to have a hard time tracking down which class to look up in MSDN to understand it's usage later on when somebody else is maintaining your code. Am I missing something?
Yes: 1. The Visual Studio IDE is happy to show you a tool tip with the fully qualified name of the class when you hover over it. 2. Visual Studio is smart enough to bring up the proper help page for a class, even when it's not fully qualified. Regards, Alvaro
The bible was written when people were even more stupid than they are today. Can you imagine that? - David Cross
-
bob16972 wrote:
"using" directives can cause name clashing, can they not?
Yes, but it's rare. The convenience of not having to always fully qualify type names far outweighs the possibility of name collisions. If a collision occurs, the compiler will let you know.
bob16972 wrote:
How exactly is someone reading the code supposed to know which namespace something is from? If you have 25 "using" statements, they are going to have a hard time tracking down which class to look up in MSDN to understand it's usage later on when somebody else is maintaining your code. Am I missing something?
Yes: 1. The Visual Studio IDE is happy to show you a tool tip with the fully qualified name of the class when you hover over it. 2. Visual Studio is smart enough to bring up the proper help page for a class, even when it's not fully qualified. Regards, Alvaro
The bible was written when people were even more stupid than they are today. Can you imagine that? - David Cross
-
Christian Graus wrote:
Given that System.Windows.Forms is scope automatically anyhow, the code should look like this: if myForms.ShowDialog = DialogResult.OK Then
Automatic due to a Koenig-like lookup, or because the wizard has injected a using System.Windows.Forms line somewhere in the file? If the former, then :cool:
-- From the Makers of Futurama
Jörgen Sigvardsson wrote:
Automatic due to a Koenig-like lookup
:-D You give them way too much credit, my friend.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
-
As far as house rule goes "Using namespace" in a header is off limits, but not in a cpp
Some of us walk the memory lane, others plummet into a rabbit hole
Tree in C# || Fold With Us! || sighistThanks to the .NET we don't have to care about headers and source files, compilation and linking anymore. Does anybody know Microsoft plans for WTF (like Windows Transofrmation Foundation) abbreviation ?
Best regards, ----------- Igor Sukhovhttp://sukhov.net
-
Thanks to the .NET we don't have to care about headers and source files, compilation and linking anymore. Does anybody know Microsoft plans for WTF (like Windows Transofrmation Foundation) abbreviation ?
Best regards, ----------- Igor Sukhovhttp://sukhov.net
Thank god!
using namespace"feels" ok in e.g. C# since it has a well defined scope.using namespacein a C++ header, otoh, is recipe for header-sorting disaster. The C++ compilation model is IMO the worst legacy about the language, and it would still be fixable.
Some of us walk the memory lane, others plummet into a rabbit hole
Tree in C# || Fold With Us! || sighist -
I was just casually strolling through VB'land and came across a question that had a snippet with this in it... If Result = System.Windows.Forms.DialogResult.OK Then I'm not a .NET person so forgive my inexperienced eyes, but are they really serious? That's quite long winded for something so trivial and probably common place. It makes me embrace my simple native loving VC++ 6.0 even tighter. This is a sad world indeed if that's progress. We are just asking for a repetitive motion injury with coding like that!
Its the same in C++, if you use namespaceing. What is bizarre is that OK, an oft used constant, should be buried so deep. I suppose it is consistent, but where would you put 'TRUE' and 'FALSE'? How about, System.Logic.Boolean.Dualisim.Values.TRUE. Or should that be System.Logic.Dualism.Boolean.Values.TRUE. Kind of makes you wonder where you fit 'mu' logic but there you go.
Tronché pas ma miche!