DeleteFile shows as DeleteFileA
in [MFC]
|
From: David Ching on 12 Apr 2010 14:22 "Pete Delgado" <Peter.Delgado(a)NoSpam.com> wrote in message news:#7bEiSm2KHA.5420(a)TK2MSFTNGP05.phx.gbl... > >> A leading '_' is reserved for compiler extensions, I believe. > > The C++ standard reserves the use of names within the global namespace > that begin with an underscore to the implementation. This means that class > members may indeed begin with an underscore because they are contained > within the class namespace. > You're right, but practically speaking it is still unwise: class MyClass { public: MyClass() { _intMember = 0; // Not obvious that _intMember is a class member and not a predefined identifier in global namespace this->_intMember = 0; // using "this->" makes it obvious it is a class member, but this is really ugly. } private: int _intMember; } So I still say using _intMember results in either ambiguity or ugliness. -- David
From: Pete Delgado on 12 Apr 2010 14:53 "David Ching" <dc(a)remove-this.dcsoft.com> wrote in message news:O3SnQ0m2KHA.1388(a)TK2MSFTNGP02.phx.gbl... > "Pete Delgado" <Peter.Delgado(a)NoSpam.com> wrote in message > news:#7bEiSm2KHA.5420(a)TK2MSFTNGP05.phx.gbl... >> >>> A leading '_' is reserved for compiler extensions, I believe. >> >> The C++ standard reserves the use of names within the global namespace >> that begin with an underscore to the implementation. This means that >> class members may indeed begin with an underscore because they are >> contained within the class namespace. >> > > You're right, but practically speaking it is still unwise: > > class MyClass > { > public: > MyClass() > { > _intMember = 0; // Not obvious that _intMember is a class member and > not a predefined identifier in global namespace > > this->_intMember = 0; // using "this->" makes it obvious it is a > class member, but this is really ugly. > } > > private: > int _intMember; > } > > > So I still say using _intMember results in either ambiguity or ugliness. Saying you *can* do something and saying you *should* do something are two totally different things! ;-) I think we could debate the merits of any naming system, but the important thing is to remain consistent within any code base. -Pete
From: David Ching on 12 Apr 2010 16:42 "Pete Delgado" <Peter.Delgado(a)NoSpam.com> wrote in message news:eM5g1Fn2KHA.3568(a)TK2MSFTNGP04.phx.gbl... > Saying you *can* do something and saying you *should* do something are two > totally different things! ;-) > > I think we could debate the merits of any naming system, but the important > thing is to remain consistent within any code base. > Right you are Pete. So along these lines, since MFC wizards generate code using m_ by default, and there is no override, I think it is fair to say that MFC apps should adopt the convention of the generated code, and start with m_. Now, what about Hungarian? I don't believe wizards generate Hungarian, yet Hungarian is used throughout the MFC source code such that if you trace into it in the debugger you will see it. Does that mean apps should also use Hungarian to remain consistent with the framework code implementation or are they free to deviate? I face the same issue with Qt, as they don't use m_ or any other convention to differentiate member variables from parameters or local variables, but I find this disturbing enough that I still do in my own Qt derived classes. Technically it is wrong, but .... where do you draw the line? -- David
From: Pete Delgado on 13 Apr 2010 13:41 "David Ching" <dc(a)remove-this.dcsoft.com> wrote in message news:eCotxCo2KHA.4336(a)TK2MSFTNGP04.phx.gbl... > "Pete Delgado" <Peter.Delgado(a)NoSpam.com> wrote in message > news:eM5g1Fn2KHA.3568(a)TK2MSFTNGP04.phx.gbl... >> Saying you *can* do something and saying you *should* do something are >> two totally different things! ;-) >> >> I think we could debate the merits of any naming system, but the >> important thing is to remain consistent within any code base. >> > > Right you are Pete. So along these lines, since MFC wizards generate code > using m_ by default, and there is no override, I think it is fair to say > that MFC apps should adopt the convention of the generated code, and start > with m_. > > Now, what about Hungarian? I don't believe wizards generate Hungarian, > yet Hungarian is used throughout the MFC source code such that if you > trace into it in the debugger you will see it. Does that mean apps should > also use Hungarian to remain consistent with the framework code > implementation or are they free to deviate? > > I face the same issue with Qt, as they don't use m_ or any other > convention to differentiate member variables from parameters or local > variables, but I find this disturbing enough that I still do in my own Qt > derived classes. Technically it is wrong, but .... where do you draw the > line? I think it is fairly easy to draw the line between the framework supplied code and any that my team and I might create... When I refer to reamining consistent with the code base, I mean that source code that is created by *your* team. If you decide that your source should adopt the conventions of another library or framework, then that is your choice. What I would hope is that within *your* source for a given project that you would see the wisdom of maintaining your conventions. -Pete
From: David Ching on 13 Apr 2010 17:59
"Pete Delgado" <Peter.Delgado(a)NoSpam.com> wrote in message news:euIK$Bz2KHA.5212(a)TK2MSFTNGP04.phx.gbl... > I think it is fairly easy to draw the line between the framework supplied > code and any that my team and I might create... > Perhaps not... for example sample code will tend to use the conventions of the framework it is the sample of, and team members copy and paste without taking care of such things..... That's why it's simpler to just adopt the convention of the framework (making sure to choose a framework which takes care of such things to your advantage, of course). > When I refer to reamining consistent with the code base, I mean that > source code that is created by *your* team. If you decide that your source > should adopt the conventions of another library or framework, then that is > your choice. What I would hope is that within *your* source for a given > project that you would see the wisdom of maintaining your conventions. > These days it's not so easy to draw the line, with "projects" having all manner of different technologies in them. For example, a project might have C++/COM, C++/MFC, Javascript, etc. Perhaps it makes more sense to say similar "modules" should have the same conventions. -- David |