DeleteFile shows as DeleteFileA
WJ
memeber function.
But in the class view, it shows as DeleteFileA(), and if I declare a
instance of this class and call DeleteFileA(), it works. In the debugger, it
goes into DeleteFile().
Why is it so? Thanks.
Alexander Grigoriev
#define DeleteFile DeleteFileA
By the way, it doesn't make sense to do non-UNICODE software anymore, which
yours seems.
"WJ" <W...@discussions.microsoft.com> wrote in message
news:65A2276D-C9E6-4E7B...@microsoft.com...
Joseph M. Newcomer
is the abstract Win32 API interface function. However, DeleteFile is a fiction; it does
not really exist. Instead, depending on your settings (you have not defined _UNICODE or
UNICODE symbols) if you are doing an "ANSI" (stupid name) build, the macro DeleteFile
expands to DeleteFileA and if you are doing a Unicode build, the macro DeleteFile expands
to DeleteFileW. It is essentially an ERROR to code it as DeleteFileA if you want
portability to Unicode, and you normally only use the -A and -W suffixes explicitly under
EXTREMELY exotic circumstances. But due to terminally stupid design, Intellinonsense
insists on giving you the API you are currently configured for, instead of the CORRECT API
name, so it takes extra effort to undo this blunder.
In the debugger, it will call either DeleteFIleA or DeleteFileW, since these are the only
APIs that exist.
joe
Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
David Webber
"Joseph M. Newcomer" <newc...@flounder.com> wrote in message
news:32opr59pg75c1qg70...@4ax.com...
>...You SHOULD be using DeleteFile, which
> is the abstract Win32 API interface function....
>... CORRECT API name...
This is a philosophical question I have been wrestling with. I have
(later than some, sooner than others) converted my char's to TCHAR's and
then defined UNICODE so that they secretly become wchar_t's (and in the
process found one or two of the exotic exceptions - in particular ASCII
character numbers turning to UNICODE code points in one or two font handling
APIs).
Now I am totally in the groove with Unicode - I love it. But the future
appears a bit misty in one respect.
I too feel that DeleteFile(), rather than DeleteFileA() or DeleteFileW(),
is the 'proper' API. Its name *feels* right. But OTOH, while TCHAR was
great for converting from char to wchar_t, I'm now so totally unicoded that
I feel I should be using wchar_t and L"Hello world" instead of TCHAR and
_T("Hello world"). But that of course means using DeleteFileW() and
friends, instead of DeleteFile() and friends, for consistency. At least
currently.
Now I *suppose* one could start using DeleteFile() with wchar_t (now that
UNICODE is defined), but that would effectively be making the assumption
that DeleteFileA() and DeleteFileW() will eventually disappear, leaving
DeleteFile() once again as the only genuine version of the API function, but
now taking wchar_t strings. Has in fact the future been thus defined?
Dave
--
David Webber
Mozart Music Software
http://www.mozart.co.uk
For discussion and support see
http://www.mozart.co.uk/mozartists/mailinglist.htm
Joseph M. Newcomer
On Wed, 7 Apr 2010 23:05:59 +0100, "David Webber" <da...@musical-dot-demon-dot-co.uk>
wrote:
>
>
>"Joseph M. Newcomer" <newc...@flounder.com> wrote in message
>news:32opr59pg75c1qg70...@4ax.com...
>
>>...You SHOULD be using DeleteFile, which
>> is the abstract Win32 API interface function....
>>... CORRECT API name...
>
>This is a philosophical question I have been wrestling with. I have
>(later than some, sooner than others) converted my char's to TCHAR's and
>then defined UNICODE so that they secretly become wchar_t's (and in the
>process found one or two of the exotic exceptions - in particular ASCII
>character numbers turning to UNICODE code points in one or two font handling
>APIs).
>
>Now I am totally in the groove with Unicode - I love it. But the future
>appears a bit misty in one respect.
>
>I too feel that DeleteFile(), rather than DeleteFileA() or DeleteFileW(),
>is the 'proper' API. Its name *feels* right. But OTOH, while TCHAR was
>great for converting from char to wchar_t, I'm now so totally unicoded that
>I feel I should be using wchar_t and L"Hello world" instead of TCHAR and
>_T("Hello world"). But that of course means using DeleteFileW() and
>friends, instead of DeleteFile() and friends, for consistency. At least
>currently.
****
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.
The failure is that Intellinonsense fails to understand the difference between what is the
official Win32 API and some random (character-set-dependent) implementation of that
interface. This is one of its numerous failures, which is why I don't ever care to use
it. I have no interest in using something that so consistently (a) gets things wrong (b)
fails to find the correct API call (c) fails to provide any useful information (such as
the decoding of UINT and DWORD flag values) when working with APIs. Since I have to bring
up the documentation anyway, I don't think it "saves" me anything. All it does is annoy
me.
****
>
>Now I *suppose* one could start using DeleteFile() with wchar_t (now that
>UNICODE is defined), but that would effectively be making the assumption
>that DeleteFileA() and DeleteFileW() will eventually disappear, leaving
>DeleteFile() once again as the only genuine version of the API function, but
>now taking wchar_t strings. Has in fact the future been thus defined?
****
The official API is defined. Intellinonsense doesn't recognize it. That is the failure
of Intellinonsense.
joe
****
>
>Dave
Giovanni Dicanio
news:Ot2PUpq1...@TK2MSFTNGP06.phx.gbl...
> This is a philosophical question I have been wrestling with. I have
[...]
> Now I *suppose* one could start using DeleteFile() with wchar_t (now that
> UNICODE is defined), but that would effectively be making the assumption
> that DeleteFileA() and DeleteFileW() will eventually disappear, leaving
> DeleteFile() once again as the only genuine version of the API function,
> but now taking wchar_t strings. Has in fact the future been thus
> defined?
Dave:
IMHO, if you don't need to support old platforms like Windows 95/98 (more
than 10 years old!), it is just fine to use wchar_t/WCHAR and DeleteFile (or
whatever API, without the "W" suffix).
Note that more modern APIs exist only in the Unicode form, e.g. :
DrawThemeText function (see the 'LPCWSTR pszText' parameter):
http://msdn.microsoft.com/en-us/library/bb773312(VS.85).aspx
Giovanni
Giovanni Dicanio
news:uefqr51j6ol89h9ac...@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#Windows_Code
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).
My 2 cents,
Giovanni
Goran
<giovanniDOTdica...@REMOVEMEgmail.com> wrote:
> "Joseph M. Newcomer" <newco...@flounder.com> ha scritto nel messaggionews:uefqr51j6ol89h9ac...@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:
>
>
> 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.
Goran.
![Doug Harrison [MVP]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjVvzhOQGbT9K0Re6Qg-OU4VGuHq0tAdTu01YlmIjUGm6t_o8g=s40-c)
Doug Harrison [MVP]
<giovanniD...@REMOVEMEgmail.com> wrote:
>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#Windows_Code
Wow, that page looks like a 100,000 character run-on sentence in Firefox.
Then I saw the NoScript "blocked" icon in the status bar. Great program,
but you always have to remember that if a site you haven't been to doesn't
look or work right, it's probably NoScript. :) (Unblocking googlecode.com
fixed it, of course.)
>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).
It does speak for itself. The problem with complex typedefs is that if you
use them at all, you must use them everywhere. If you had LPWSTR but not
LPCWSTR, it would be a huge mistake to try to fake it as "const LPWSTR".
--
Doug Harrison
Visual C++ MVP
Joseph M. Newcomer
On Thu, 8 Apr 2010 11:37:02 +0200, "Giovanni Dicanio"
<giovanniD...@REMOVEMEgmail.com> wrote:
>"Joseph M. Newcomer" <newc...@flounder.com> ha scritto nel messaggio
>news:uefqr51j6ol89h9ac...@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?
****
Depends on what standard I'm trying to follow. But wchar_t does not exist in any API
parameter list or as a return type; LPTSTR is the encoding-neutral form, and if you read
any code it uses LPWSTR and LPCWSTR as the parameter types. Therefore, it is unnatural in
writing WIndows code to drop down to the low-level implmentation. I also do not use
'unsigned int' for UINT, 'unsigned long' for ULONG or DWORD, and so on. When interfacing
to API calls, I use BOOL if the call uses BOOL (and I don't use bool unless I'm writing
std::-related code)
****
>
>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.
****
Consistency with Windows programming styles.
****
>
>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#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.
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.
****
>
>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).
>
****
And this opinion of one programmer proves what? Note that noplace in the Win32 API is
const WCHAR * used; instead, LPCWSTR is used.
joe
****
>My 2 cents,
>Giovanni
Joseph M. Newcomer
****
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.
Liviu
>
> 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
Hector Santos
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
Giovanni Dicanio
> 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
Hector Santos
especially when reading other people code and prototypes, and still
use it for the most part, especially when I am first designing
something and need to keep my mental thinking straight.
But I will also sometimes not use it if the variable is common sense
too, although I might go back to add prefixes or even remove them. :)
Plus with the many different languages and methods (i.e. oops) I use,
I find myself mixing it up. For example under a language like
javascript, you would follow its practices, but I mix it up too. :)
That includes lower case vs high case functions:
getThat()
GetThat()
I sorta like the PHP notation, I guess because I have been finding
myself using it more for documentation in a mix language world.
For example, even for a C/C++ or BASIC audience, I might use this:
bool XYZ(string, array, integer)
just to get the point across.
I don't think I am the exception with other designers and developers
"Mixing it up."
Giovanni Dicanio wrote:
--
HLS
Goran
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.
Goran
<giovanniDOTdica...@REMOVEMEgmail.com> wrote:
> "Joseph M. Newcomer" <newco...@flounder.com> ha scritto nel messaggionews:rbtsr557i53km7r9f...@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)?
Giovanni Dicanio
news:3d8eb75b-8d6f-4036...@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
David Ching
news:9891b928-3a77-4738...@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
Joseph M. Newcomer
On Fri, 9 Apr 2010 11:09:28 +0200, "Giovanni Dicanio"
<giovanniD...@REMOVEMEgmail.com> wrote:
>"Joseph M. Newcomer" <newc...@flounder.com> ha scritto nel messaggio
>news:rbtsr557i53km7r9f...@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
****
Joseph M. Newcomer
On Fri, 09 Apr 2010 08:11:44 -0400, Hector Santos <sant...@nospam.gmail.com> wrote:
>Like Joe, I grew up with Hungarian notation. I still prefer it,
>especially when reading other people code and prototypes, and still
>use it for the most part, especially when I am first designing
>something and need to keep my mental thinking straight.
****
Like "DWORD lpstrAlgorithm" and "UINT wID" (the types are inconsistent with the HN
variable names; these are excerpts from actual Windows header files!) I have learned that
if you trust someone else's HN, you will find they have misused it, and you become
confused. So I simply don't trust it, ever; I've been done in far too often by bad usage.
****
>
>But I will also sometimes not use it if the variable is common sense
>too, although I might go back to add prefixes or even remove them. :)
>
>Plus with the many different languages and methods (i.e. oops) I use,
>I find myself mixing it up. For example under a language like
>javascript, you would follow its practices, but I mix it up too. :)
>
>That includes lower case vs high case functions:
>
> getThat()
> GetThat()
>
>I sorta like the PHP notation, I guess because I have been finding
>myself using it more for documentation in a mix language world.
>
>For example, even for a C/C++ or BASIC audience, I might use this:
>
> bool XYZ(string, array, integer)
>
>just to get the point across.
>
>I don't think I am the exception with other designers and developers
>"Mixing it up."
****
HN is poorly used within WIndows; in fact, one correspondent, reading my HN diatribe,
pointed out that the Windows group came to the Word group and saw HN, and instead of using
the ABSTRACT data type as the prefix, decided to use the IMPLMENTATION type, which he says
violates the fundamental principles of HN design. So he claims the WIndows group got it
all wrong, and all problems stem from their failure to understand HN as designed.
Also, it was only really necessary in the days before ANSI C with prototypes, because a
programmer had to read a declaration
bool XYZ(lptstrName, arData, iIndex)
because the C language did not include types in the header files, so this was a substitute
for ANSI prototypes. Now that ANSI C exists, HN has no particular value any longer!
joe
****
Liviu
"Goran" <goran...@gmail.com> wrote...
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
Joseph M. Newcomer
****
What I tell my students:
"Someday, your boss is going to drop in and say 'We just landed a big contract in <Japan,
Korea, China>. How soon can you have the software ready to run there"
Which answer do you want to give
(a) Give me a couple days, and I'll be able to give you an estimate. Three to six
weeks, probably
(b) How soon can you get the translator in here?
The reality is that we live in a very global market, and anyone who knows their company
product will never need Unicode is living in a fantasy world.
And if you thnk UTF-8 makes it easy, you have never actually had to deal with a language
that used a multibyte encoding in UTF-8. It is NOT easy, and is highly error-prone. I
know, I've had to clean up some of the messes that have resulted from this. First thing I
do is convert to Unicode. Then REMOVE all the erroneous code that was failing to deal
with UTF-8 or MBCS properly. If I use UTF-8, it is at the boundaries (write UTF-8 files,
read them, use it across network packets, etc.)
joe
****
>
>Liviu
Joseph M. Newcomer
****
It will be very unpleasant. I've seen cases where people are passing UTF-8-encoded
filenames to the CreateFIleA API and wondering why the filenames "look funny".
****
>
>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.
****
Win32 API does not understand UTF-8 (it is not clear how well it works with UTF-16 with
surrogates, either!). But for a large class of languages, it works well in UTF-16. The
only question is when there is going to be the massive shift to UTF-32 encoding, now that
Unicode has changed (when Windows was designed, Unicode did not actually use any encoding
larger than 16 bits)
joe
****
>
>Goran.
Hector Santos
BTW I really need to better learn this UNICODE crap. :)
Not sure if its related, maybe Goran to provide insight, I seem to
recall the need to use some OEM function in an old piece of code
related to this, I think, let me check..... Yeah...
SetFileApisToOem()
Back in 1999, I forget the details, but we had to use it for an
console utility to help prepare finish the installation upgrade of a
locked file using the reboot procedure; MoveFileEx() for NT based
systems or preparing the wininit.ini.
Here is the C code I had, again, I don't recall the specifics why it
was needed. It might have been because we needed to make sure it
worked for Win95 as well.
// file: sysmove.cpp
#include <stdio.h>
#include <windows.h>
int main(int argc, char *argv[])
{
char src[MAX_PATH] = {0};
char tar[MAX_PATH] = {0};
if (argc < 3) {
printf("SysMove v1.1 (c)1999 Santronics Software Inc\n");
printf("Prepares a system file for replace upon reboot.\n");
printf("usage> sysmove sourcefile targetfile\n");
return 1;
}
if (argc > 1) strncpy(src,argv[1], sizeof(src)-1);
if (argc > 2) strncpy(tar,argv[2], sizeof(tar)-1);
SetFileApisToOEM();
OSVERSIONINFO osv = {0};
osv.dwOSVersionInfoSize = sizeof(osv);
GetVersionEx(&osv);
if (osv.dwPlatformId == VER_PLATFORM_WIN32_NT) {
printf("* Windows NT-based system\n");
if (!MoveFileEx(src,tar,
MOVEFILE_DELAY_UNTIL_REBOOT |
MOVEFILE_REPLACE_EXISTING)) {
printf("! MoveFileEx error %d\n", GetLastError());
return 1;
}
}
else { // assume Win95
printf("* Windows 95\n");
if (!WritePrivateProfileString("rename",src,tar,"wininit.ini")) {
printf("! error %d - wininit.ini\n", GetLastError());
return 1;
}
}
printf("! Successful System File Move Preparation. Now reboot.");
return 0;
}
--
HLS
Giovanni Dicanio
news:9891b928-3a77-4738...@11g2000yqr.googlegroups.com...
> BTW, I believe that Spolsky is right on Hungarian in
> http://www.joelonsoftware.com/articles/Wrong.html
Very interesting article, thanks!
I agree that Hungarian can be of a good help when it identifies the *intent*
(more than the underlying raw type).
For example, both BSTR and LPWSTR are wchar_t*, and the following code would
compile just fine:
LPWSTR s1;
BSTR s2;
...
s2 = s1;
But it is *wrong*, because BSTR's must be allocated using their own
functions like SysAllocString, etc.
Using a proper prefix convention helps identifying the problem (especially
when the offending code is sorrounded by other code):
LPWSTR pszS1;
BSTR bstrS2;
...
bstrS2 = pszS1;
--> wrong: can't assign a BSTR from raw LPWSTR.
Another good example is the consistent use of 'cb' vs 'cch'.
Or prefixing pointers with 'p'...
WCHAR szBuf[100];
...
LPWSTR pszBuf;
...
StringCbCopy(..., sizeof(pszBuf) ... )
Reading sizeof(*p*szBuf) alerts the brain, because the size of a *p*ointer
is 4, and probably what was needed was the size of the statically-allocated
buffer (i.e. sizeof(szBuf), without the leading 'p').
And I like the cancelation rule of 'p' and '*'.
For example:
BYTE **ppb
*ppb is a BYTE*, because the first * and the first 'p' cancel together, so
'pb' remains (and it is a single-level pointer).
> 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)?
I like the 'm_' prefix, probably because I'm used to it, and to me it is
consistent with g_ and s_ prefixes I use for global variables and static
variables.
(Yes, I know that modern IDEs use tooltips to give information about an
identifier, but I just find it more readable having it standing, speaking
for itself.)
However, all in all, I do like David's words:
> 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.
Giovanni
Liviu
> On Thu, 8 Apr 2010 20:48:19 -0500, "Liviu" <lab...@gmail.c0m> wrote:
>
>> 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.
> ****
>
> knows their company product will never need Unicode is living in a
> fantasy world.
Right. To be very clear, my point was not against Unicode as the
standard, but only the implementation choice of a particular encoding
such as UTF-8 or UTF-16 for internal representation.
> And if you thnk UTF-8 makes it easy, you have never actually had
> to deal with a language that used a multibyte encoding in UTF-8.
> It is NOT easy, and is highly error-prone. I know, I've had to clean
> up some of the messes that have resulted from this. First thing I do
> is convert to Unicode. Then [...]
Then the app fails to run because its VM size suddenly shot over 2GB,
and now you have to rebuild it for 64b, and require your clients to
upgrade their windows as well ;-) Mostly joking, of course... But as
long as the code does meet the Unicode requirements, the choice for
its internal encoding is an engineering decision more than a design one.
Liviu
Joseph M. Newcomer
<giovanniD...@REMOVEMEgmail.com> wrote:
>"Goran" <goran...@gmail.com> ha scritto nel messaggio
>news:9891b928-3a77-4738...@11g2000yqr.googlegroups.com...
>
>> BTW, I believe that Spolsky is right on Hungarian in
>> http://www.joelonsoftware.com/articles/Wrong.html
>
****
Actually, this "right" way is not particularly right. The REALLY right way is to define a
string class SafeString, and only allow operations on SafeString variables. By using the
name instead of the type, you allow
sData = usData;
to compile, when in fact you don't want this to jump out visually to you at all! You want
the code to NOT COMPILE!
I once worked in a language that had nice features, and I wrote graphics code with two
data types, Xint and Yint, which represented the coordinate system. So you couldn't
accidentally store an X-coordinate in a Y-coordinate variable. And when I did this, I
found someone had written a subroutine that took the Y coordinate FIRST (stupid design
decision, not mine, either) and so the program stopped compiling! THAT'S what you want
from notations. Use the type system, not the programmer, to detect these kinds of errors!
Microsoft has been abysmal at this; the fact that LPWSTR and BSTR could cross-assign is a
total design failure of BSTR.
Don't use a kludge to fix a very real problem; use types. The problem was that C
programmers think C++ is just C with funny syntax, and it is not. It is a new language,
and it should be used to its full power. Creating silly names like "s"-prefix variables
and "us"-prefix variables says "I'm an incompetent C++ programmer, using some lazy
solution instead of building the right one!". You can do the same thing in C, using
structs (it is clumsy, but I've done it).
On large projects, a bit of investment in infrastructure pays off in higher productivty,
reliability, and robustness. DO THE JOB RIGHT! USE TYPES!
I haven't worked on a project larger than one person in twenty years, and I still create
funky types to deal with places where I care about type safety. If I were back working on
20-person teams, I'd be spending a LOT of time doing this (back when I was, I did).
Note that we could NOT assign literals to X or Y coordinates, if you needed a (0,0)
coordinate, you had to write the equivalent of
Coordinate origin(Xint ! 0, Yint ! 0);
"!" was the casting operator, and a casting operator was defined for the type so you could
limit what appeared on the RHS of the infix operator. So it was essentially
class Xint {
... stuff
Xint operator ! (int v) { return reinterpret_cast<XInt>(v); }
}
Also, we didn't have to define every operator because we could derive from a higher level
and not end up allowing arguments of the subclass to match parameters of the superclass
(it had an amazing type system, the best I've ever worked in).
except that isn't quite the syntax of that language that I used.. But it conveys the
idea.
****
****
I find the m_ prefix offensive in that it demands a purely arbitrary convention that
cannot be enforced by the language or compiler. Since I do not think it adds anything to
the program readability, and in fact is completely noise most of the time, I have not used
it in years. I only used it in two programs. The first two MFC programs I wrote.
****
>
>(Yes, I know that modern IDEs use tooltips to give information about an
>identifier, but I just find it more readable having it standing, speaking
>for itself.)
>
>However, all in all, I do like David's words:
>
> > 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.
>
>
>Giovanni
>
>
Joseph M. Newcomer
****
If a minor change like moving to Unicode blows you out of the water like this, it suggests
you were already living dangerously. Something that gratuitously generates a > 1GB memory
footprint has deeper problems than Unicode. Memory footprints this large inevitably have
horrible performance characteristics, and these need to be solved.
Some years ago, I had to deal with a WIn16 program that had a 7.5MB footprint on a 2MB
machine (remember when we could run productive code on a 2MB machine?) Once I replaced
all the fixed-size arrays of characters with dynamically-allocated strings, and the
fixed-size-arrays-of-structs-with-fixed-sized-arrays-of-things-inside-them with
dynamically-allocated objects, in 3 days I recoded this C program to have a 300K
footprint. And we stopped, because that was Good Enough. But if converting to Unicode
blows your memory size, I think there are deeper problems that need to be addressed, ones
which will result in substantially smaller memory footprints if addressed properly.
I learned this programming on small machines (64K to 1MB machines). Programs whose size
grows usually represent less-than-optimal designs; at some level, the small memory imposes
ridiculous design decisions (I built several "overlay" systems to handle large code bases,
and they were a real pain to deal with; and building virtual memory systems that kept
strings in mapped files was also a pain) but once we start complaining that 1GB or 2GB is
too small, either the design is wrong, or you really SHOULD have a 64-bit machine (my
database friends LOVE Win64!) because the problem really is of that scale.
If you are willing to pay the price in complexity for UTF-8, fine, but going into the
problem you need to realize that you are trading off a LOT of coding complexity to keep
the footprint small (most people who do this don't get the code right, and it breaks
horribly every time you throw a multibyte character into the mix! Been there, fixed that)
Joseph M. Newcomer
On Fri, 09 Apr 2010 12:03:09 -0400, Hector Santos <sant...@nospam.gmail.com> wrote:
>Giovanni Dicanio wrote:
>
>> "Goran" <goran...@gmail.com> ha scritto nel messaggio
>> news:3d8eb75b-8d6f-4036...@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
>
>
>BTW I really need to better learn this UNICODE crap. :)
>
>Not sure if its related, maybe Goran to provide insight, I seem to
>recall the need to use some OEM function in an old piece of code
>related to this, I think, let me check..... Yeah...
>
> SetFileApisToOem()
*****
Yes, this really was an ugly set of problems, largely caused by a failure of Microsoft to
handle file updates properly. I forgot about the use of the OEM character set, required
due to some other set of horrible bugs. And we had to use the short (8.3) compatible
paths and had to call the APIs to change them. Truly ugly beyond belief.
Which is why we stopped trying to write installer code and started using commercial
installer programs. The last installer I wrote was back around 2000, and only because
they paid me lots and lots of money to get it right. I would never do that again.
joe
****
****
Actually, we had to lock the file, memory-map it, expand it and insert the filename in the
middle somewhere. We used code from Jeff Richter's book where he showed how to do this
for Win32.
joe
****
> return 1;
> }
> }
> printf("! Successful System File Move Preparation. Now reboot.");
> return 0;
>}
Joseph M. Newcomer
It defined a set of strings. For the Win16 app, I wrote
... = DoSomething(SYMBOLIC_NAME_OF_STRING_HERE)
and for the Win32 app I wrote
... = DoSomethingA(SYMBOLIC_NAME_OF_STRING_HERE)
There were some very odd reasons I could not write
... = DoSomething(_T(SYMBOLIC_NAME_OF_STRING_HERE));
that dealt with how the header files were shared and which code was shared and how, and I
would not do it that way today. But it was code I wrote in 1996.
It is one of the very few times I had to explicitly call an -A or -W suffix API.
joe
Alexander Grigoriev
webpage encodings can just go away.
"Joseph M. Newcomer" <newc...@flounder.com> wrote in message
news:p4iur51d8pqca33r7...@4ax.com...
Liviu
"Joseph M. Newcomer" <newc...@flounder.com> wrote...
> On Fri, 9 Apr 2010 17:55:35 -0500, "Liviu" <lab...@gmail.c0m> wrote:
>>
>>Then the app fails to run because its VM size suddenly shot over 2GB,
>>and now you have to rebuild it for 64b, and require your clients to
>>upgrade their windows as well ;-) Mostly joking, of course... But as
>>long as the code does meet the Unicode requirements, the choice for
>>its internal encoding is an engineering decision more than a design
>>one.
> ****
> If a minor change like moving to Unicode blows you out of the water
> like this, it suggests you were already living dangerously. Something
> that gratuitously generates a > 1GB memory footprint has deeper
> problems than Unicode. Memory footprints this large inevitably have
> horrible performance characteristics, and these need to be solved.
I resent the "gratuitously" insinuation ;-) I've grown up on scarce
resource systems decades ago and still remember what decus/hisoft/aztec
meant as far as C goes on platforms long forgotten now. But that's way
off-topic... Case in point was not about wasteful design or even "near
the edge" living. Just that (few, but some) users get caught in the
ever-bigger hyperbole and push the limits just for the fun of it. They
can understand that an (artificial) test case many times larger than
what was billed or sold would run slower, but if they get an "out of
memory" error they would still complain that their new machine has
plenty of memory available. Even those who run 32b XP on 8GB ;-)
> once we start complaining that 1GB or 2GB is too small, either the
> design is wrong, or you really SHOULD have a 64-bit machine
The latter. But that's an idea far easier to sell today than, say, 5 yrs
ago. Of course, tomorrow we could have a similar argument about
UTF-32 encoding. I actually wonder whether that's in MS's books.
Liviu
Pete Delgado
"David Ching" <d...@remove-this.dcsoft.com> wrote in message
news:%23MKaTb$1KHA...@TK2MSFTNGP06.phx.gbl...
> "Goran" <goran...@gmail.com> wrote in message
> news:9891b928-3a77-4738...@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.
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.
-Pete
David Ching
news:#7bEiSm2...@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
Pete Delgado
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
David Ching
> 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
Pete Delgado
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
David Ching
> 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
Joseph M. Newcomer
the implementation of code written by programmers outside the compiler environment".
So it is still bad style to use this technique in any user-written code; it is reserved
for the implementors of the C/C++ runtimes.
joe
Pete Delgado
> 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.
I could live with that wording! :-)
-Pete