On 04.01.2012 15:32, Ulrich Eckhardt wrote:
> Am 04.01.2012 02:18, schrieb Alf P. Steinbach:
>> On 03.01.2012 23:33, RaZiel wrote:
>>> On 28.12.2011 05:36, Alf P. Steinbach wrote:
>>>> <url:
>>>>
http://learnwinapi.wordpress.com/2011/12/28/lesson-4-dialogs-and-resources/>
>>>>
>>>>
>>>
>>> Excuse my ignorance. Why does WindowSpec contain a construtor? Isn't it
>>> a POD?
>>
>> Repeating the answer I posted to the same question on the blog:
>>
>>
>> <quote>
>> Well, WindowSpec has a constructor just for convenience. [...]
>> </quote>
>
> I think factory function are a good alternative, especially if you want
> to keep the compiler-generated default constructor and
> by-any-C++-standard POD-ness.
Factory functions are nice for some things, but in general and in this
case it's just more to write than simply defining a constructor.
In other words, there was no particular reason to use a factory function.
> That said, what I find unclear is the point of single-wchar_t fields in
> that struct. I have an idea what this hack does and how it works, but
> putting that into public members seems like a bad idea to me.
They represent the terminating nulls of null-terminated strings.
> Another thing I noticed on cursory reading was that you explicitly use
> wchar_t but neither MESSAGEBOXPARAMSW nor MessageBoxIndirectW().
[windows.h] does not IMHO define any better, more readable name for
`wchar_t`.
However, [windows.h] does define e.g. MSGBOXPARAMS as a more readable
alternative for MSGBOXPARAMSW, and it is not only more readable but also
more easy to look up in the documentation (e.g., right-click and google).
In modern Windows programming there is no practical reason to reserve
that name for places where it might work to instead have it defined as
MSGBOXPARAMSA, since (one just ensures that) it will never be defined as
anything but MSGBOXPARAMSW.
> Cheers and thank you anyway!
>
> Uli
Cheers,
- ALf