From: Goran on
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
"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
"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
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

"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


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8
Prev: Setting PropertySheet Title (Wizard mode)
Next: strsafe.lib