Ann: lesson 4 in Windows API level GUI programming "Dialogs and resources"

[Alf P. Steinbach]

<url:
http://learnwinapi.wordpress.com/2011/12/28/lesson-4-dialogs-and-resources/>

Cheers & enjoy,

- Alf

 

[RaZiel]

<url:
http://learnwinapi.wordpress.com/2011/12/28/lesson-4-dialogs-and-resources/>


Cheers & enjoy,

- Alf

Excuse my ignorance. Why does WindowSpec contain a construtor? Isn't it
a POD?

- RaZ

 

[Christopher]

<url:http://learnwinapi.wordpress.com/2011/12/28/lesson-4-dialogs-and-reso...>

Cheers & enjoy,

- Alf

I don't understand these posts anymore. I was under the impression
that Alf usually complained about some short coming of Windows as it
relates to C++ and Leigh would argue back, triggering an argument from
Alf, and etc. etc. Did I get it mixed up and Alf is the Windows
proponent and Leight is not? I need to understand the characters in
this drama.

 

[Alf P. Steinbach]

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. By C++98/C++03
rules it’s therefore not a POD. By C++11 rules it is however a standard
layout class.

I am not sure of whether it is POD by the more relaxed C++11 rules. The
C++11 definition of POD is essentially that the class is both trivial
and standard-layout. But the definition of “trivial” is, as I see it,
open for interpretation, at least for pedantically formal folks.

Anyway, it’s just a convenience class, and since it relies on
assumptions about memory layout, it is very system-specific (but should
work with any Windows compiler). I started writing that code using a
std::vector<Byte> where I serialized the data, which would have have
yielded code that in principle could be more portable, but then I caught
myself: hey, introducing complexity to get system portable code for
Windows API? It was just reflex coding. So then I intentionally reworked
and simplified that as system-specific code.
</quote>


Cheers & hth.,

- Alf

 

[Ian Collins]

Me?

I think Windows is a fine OS but Microsoft's Windows C++ support not so
much; I didn't used to mind MFC but I have recently decided that it
really is a bag of shite and as a result of this and for other reasons I
am creating my own cross-platform C++ GUI lib which you can check out at
http://neogfx.org if interested (work in progress, hopefully out in 2012).

Another one? Aren't there enough already?

 

[Miles Bader]

There will never be enough.

Maybe one of these days, somebody will finally get it right...

-miles

 

[Ulrich Eckhardt]

Am 04.01.2012 02:18, schrieb Alf P. Steinbach:

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.

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.

Another thing I noticed on cursory reading was that you explicitly use
wchar_t but neither MESSAGEBOXPARAMSW nor MessageBoxIndirectW().

Cheers and thank you anyway!

Uli

 

[Alf P. Steinbach]

Am 04.01.2012 02:18, schrieb Alf P. Steinbach:

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