DeleteFile shows as DeleteFileA
in [MFC]
|
From: Joseph M. Newcomer on 8 Apr 2010 20:49 See below... On Thu, 8 Apr 2010 07:27:32 -0700 (PDT), Goran <goran.pusic(a)gmail.com> wrote: >On Apr 8, 11:37�am, "Giovanni Dicanio" ><giovanniDOTdica...(a)REMOVEMEgmail.com> wrote: >> "Joseph M. Newcomer" <newco...(a)flounder.com> ha scritto nel messaggionews:uefqr51j6ol89h9ac0t93c2qs0015abbf6(a)4ax.com... >> >> > Actually, you would be using WCHAR, LPWSTR, and LPCWSTR. �There is very >> > little reason in >> > Windows programming to ever use wchar_t as a data type. >> >> Why? >> Do you use INT instead of int? >> Or BOOL instead of bool? >> Or VOID instead of void? >> >> I fail to see a reason why one should use WCHAR instead of wchar_t (to me, >> probably the only reason is that it is shorter to type :) >> I mean: I see this just as a personal programming style. >> >> Note also that if you read Google C++ Coding Style document, in particular >> the section about Windows code: >> >> �http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Window... >> >> they tend to prefer 'const WCHAR *' instead of LPCWSTR (and frankly >> speaking, I find it more readable and its intent more clear, especially to a >> Win32 beginner programmer). > >I don't care about const WCHAR* versus LPCWSTR either (and it should >be noted that this L there stands out like a sore thumb). > >The part about exceptions is clueless, though. There is no C++ without >exceptions, and it's not MS implementation of STL that throws, it's >__ANY__ implementation. I mean, how do they think that e.g. >vector::push_back should react if it has to re-allocate contents and >that fails? That will throw an exception, MS or not, or die with >segmentation fault if operator new is rigged to return NULL on >failure. (Under a system with overcommit, e.g. Linux, it might be that >process will be killed __later__ by OOM killer, but that's something >else). > >WRT exceptions, their style guide has serious delusions. It is frankly >amazing that such a well-known document from a major company contains >such drastic logic flaws. > >I think I know where they are coming from - they think that, because >they have big code base that is not exception safe, they can just >waive exceptions out by saying "thou shalt not throw". But the problem >is, they themselves will use libraries (e.g. STL), or cpp runtime, >that throw (per standard, operator new shall throw - what then? The >best they can do is to rig it to terminate the process, I guess). >Google should sort themselves out there. **** Also, they use the boost libraries, which the last time I looked, threw exceptions. Code which is not exception-safe is sloppy code. And yes, some of my code will end up treating any excpetion as a fatal condition because it is not really exception-safe, and writing exception-safe code is HARD! My clients are unwilling to pay for exception-safe code; this doesn't mean that I shouldn't be prepared to handle certain exceptions, but we know from concepts of scaling that, for example, we will never run out of memory in a real instance of the app. joe **** > >Goran. 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 8 Apr 2010 21:48 "Alexander Grigoriev" <alegr(a)earthlink.net> wrote... > > See windows.h: > > #define DeleteFile DeleteFileA > > By the way, it doesn't make sense to do non-UNICODE software > anymore, which yours seems. If you meant strictly that DeleteFileA doesn't make sense then I'll agree (same applies to most other Win32 API calls for that matter). And if you meant that apps need be Unicode aware then I'll agree, too. 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. Liviu
From: Hector Santos on 9 Apr 2010 05:03 Liviu wrote: > "Alexander Grigoriev" <alegr(a)earthlink.net> wrote... >> See windows.h: >> >> #define DeleteFile DeleteFileA >> >> By the way, it doesn't make sense to do non-UNICODE software >> anymore, which yours seems. > > If you meant strictly that DeleteFileA doesn't make sense then I'll > agree (same applies to most other Win32 API calls for that matter). > And if you meant that apps need be Unicode aware then I'll agree, too. > > 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. > > Liviu What is interesting is that it (the statement) reflects how global we become. To me, UNICODE is a kludge and just preaches wasted slack space. I use it only when/where necessary. -- HLS
From: Giovanni Dicanio on 9 Apr 2010 05:09 "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... 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 >> >> 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.) > 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. Giovanni
From: Goran on 9 Apr 2010 08:23
On Apr 9, 3:48 am, "Liviu" <lab...(a)gmail.c0m> wrote: > "Alexander Grigoriev" <al...(a)earthlink.net> wrote... > > > See windows.h: > > > #define DeleteFile DeleteFileA > > > By the way, it doesn't make sense to do non-UNICODE software > > anymore, which yours seems. > > If you meant strictly that DeleteFileA doesn't make sense then I'll > agree (same applies to most other Win32 API calls for that matter). > And if you meant that apps need be Unicode aware then I'll agree, too. > > 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. 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. Goran. |