DeleteFile shows as DeleteFileA
in [MFC]
|
From: Goran on 9 Apr 2010 08:32 On Apr 9, 11:09 am, "Giovanni Dicanio" <giovanniDOTdica...(a)REMOVEMEgmail.com> wrote: > "Joseph M. Newcomer" <newco...(a)flounder.com> ha scritto nel messaggionews:rbtsr557i53km7r9fm3ihutegm5cmscih0(a)4ax.com... > > > Consistency with Windows programming styles. > > OK, Joe. > > But note that "Windows programming style" is sometimes not coherent itself. > > For example, sometimes in the API they use 'dw' prefix for a DWORD that > represents a length of a buffer or something, in other cases they use 'cb' > prefix... > > Or sometimes the prefix for UINT is 'u', other times is 'w' or 'cch'... > For example read here: > > IContextMenu::GetCommandString Method > http://msdn.microsoft.com/en-us/library/bb776094(VS.85).aspx > > You can read: > > UINT uFlags > UINT *pwReserved (...why not 'puReserved' ?) > UINT cchMax I practically always despised Hungarian. But it's the norm with MFC code and I am using it day in day out and thinking "life is not perfect". I realize that it was somewhat important in days of poorer C compilers, but today, it's just screen noise. BTW, I believe that Spolsky is right on Hungarian in http://www.joelonsoftware.com/articles/Wrong.html (see the "Simonyi was right, the rest of the world is wrong" part; yes, that includes you, me, MFC and Windows headers). Goran. P.S. "m_"!? Puh-lease! Ok, I agree that it's interesting to prefix class data members, but what's wrong with a simple "_", or "F" (for "field", as Borland does)?
From: Giovanni Dicanio on 9 Apr 2010 09:10 "Goran" <goran.pusic(a)gmail.com> ha scritto nel messaggio news:3d8eb75b-8d6f-4036-b3c0-2ee0b0f80dbe(a)u34g2000yqu.googlegroups.com... > Passing that UTF-8 string to DeleteFile (that is, "A" version will be > picked by the compiler) is quite likely to lead to trouble, and a +/- > subtle one (system presumes "ANSI" encoding, whereas string passed in > ain't that). So, conversion from UTF-8 to corresponding code page is > both restrictive and necessary. > > So even if UTF-8 is used, it's better to define (_)UNICODE and to make > it a habit to go to UTF-16 before going to Win32. Very good point, Goran! Giovanni
From: David Ching on 9 Apr 2010 11:10 "Goran" <goran.pusic(a)gmail.com> wrote in message news:9891b928-3a77-4738-aedb-0a6671fd1656(a)11g2000yqr.googlegroups.com... > P.S. "m_"!? Puh-lease! Ok, I agree that it's interesting to prefix > class data members, but what's wrong with a simple "_", or "F" (for > "field", as Borland does)? A leading '_' is reserved for compiler extensions, I believe. A trailing '_' looks plain weird and distracts readability. I've never seen 'F' but don't believe I would like it due to it's uppercase. "m_" isn't perfect, but it's what I'm used to, and so is the best! :-) Actually, it's more important to be consistent with the other code you're working with, because jumping from one convention to another while stepping into other people's code in the debugger or editor is more jarring than staying with one non-optimal convention. -- David
From: Joseph M. Newcomer on 9 Apr 2010 11:24 See below... On Fri, 9 Apr 2010 11:09:28 +0200, "Giovanni Dicanio" <giovanniDOTdicanio(a)REMOVEMEgmail.com> wrote: >"Joseph M. Newcomer" <newcomer(a)flounder.com> ha scritto nel messaggio >news:rbtsr557i53km7r9fm3ihutegm5cmscih0(a)4ax.com... > >> Consistency with Windows programming styles. > >OK, Joe. > >But note that "Windows programming style" is sometimes not coherent itself. > >For example, sometimes in the API they use 'dw' prefix for a DWORD that >represents a length of a buffer or something, in other cases they use 'cb' >prefix... **** Since NOBODY (least of all Microsoft) can use the brain-dead interpretation of HN the WIndows group adopted, I'm not surprised. However, I'm not sure how we shifted from type names to variable names in this discussion; the API is suprisingly consistent with respect to the use of type names. **** > >Or sometimes the prefix for UINT is 'u', other times is 'w' or 'cch'... >For example read here: **** I have never see a typed called uINT or wINT or cchINT. You have shifted from the domain of type names (which is what was originally under discussion) to the domain of HN variable names (which has always been screwed up and is beneath contempt) **** > > IContextMenu::GetCommandString Method > http://msdn.microsoft.com/en-us/library/bb776094(VS.85).aspx > >You can read: > > UINT uFlags > UINT *pwReserved (...why not 'puReserved' ?) > UINT cchMax > > >>> >>> http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Windows_Code >> **** >> I'm supposed to take SERIOUSLY a style guide that does not allow >> pass-by-reference EXCEPT >> for const references? In fact, non-const references are very powerful >> and very important >> to me. > >If you expand the paragraph, you can read both the pros and the cons. >Their cons are: "References can be confusing, as they have value syntax but >pointer semantics." >(I'm not saying I agree with them on this, though.) **** Any C++ programmer knows the difference; this error applies only to amateurs who think that you have to have pointer syntax at the call site to pass a "reference". Experienced C++ programmers know you can pass by reference and it doesn't bother them at all to look at the definition of the called function. But if the comments were important, they would have been in the document directly and not require scripting to make visible. So the document is written by amateurs who do not understand how to write decent documentation. *** > > >> The only comment I found about 'const' was that it should be used wherever >> it makes sense. >> If there was something else to say, it was obviously not important enough >> to say in the >> document. Because of security, the silly buttons did nothing. Silly >> buttons like this >> serve no useful purpose except to look cute. > >The "silly buttons" :) allow to expand the text and read an elaborated >explanation for the particular paragraph or style rule. **** It does not make them less silly. In a real document, the text would be visible without requiring JavaVirus to attack my computer. joe **** > > >Giovanni > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Liviu on 9 Apr 2010 11:33
"Goran" <goran.pusic(a)gmail.com> wrote... > On Apr 9, 3:48 am, "Liviu" <lab...(a)gmail.c0m> wrote: >> >> But the blanket statement that non-UNICODE software should be >> shunned is too strong IMHO. There still are cases where it makes >> a lot of sense to build non-Unicode (i.e. no _UNICODE or UNICODE >> #define'd) and explicity call the "W" flavor of the API functions >> where applicable. One example at random, an application which >> stores text as UTF-8 internally, and does more string manipulations >> inside than API calls outside. > > Passing that UTF-8 string to DeleteFile (that is, "A" version will be > picked by the compiler) is quite likely to lead to trouble, and a +/- > subtle one (system presumes "ANSI" encoding, whereas string passed > in ain't that). So, conversion from UTF-8 to corresponding code page > is both restrictive and necessary. True. But you missed the part where I said 'explicity call the "W" flavor of the API functions where applicable'. In this case it would mean converting UTF-8 to UTF-16, then calling DeleteFileW. > So even if UTF-8 is used, it's better to define (_)UNICODE Then one would have to explicitly use the "A" functions (lsrtlenA) and objects (CStringA) for internal UTF-8 manipulations. Liviu |