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

Discussion in 'C++' started by Alf P. Steinbach, Dec 28, 2011.

  1. Alf P. Steinbach, Dec 28, 2011
    1. Advertisements

  2. Alf P. Steinbach

    RaZiel Guest

    RaZiel, Jan 3, 2012
    1. Advertisements

  3. Alf P. Steinbach

    Christopher Guest

    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.
    Christopher, Jan 4, 2012
  4. Repeating the answer I posted to the same question on the blog:

    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. :)

    Cheers & hth.,

    - Alf
    Alf P. Steinbach, Jan 4, 2012
  5. Alf P. Steinbach

    Ian Collins Guest

    Another one? Aren't there enough already?
    Ian Collins, Jan 4, 2012
  6. Alf P. Steinbach

    Miles Bader Guest

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

    Miles Bader, Jan 4, 2012
  7. Am 04.01.2012 02:18, schrieb Alf P. Steinbach:
    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!

    Ulrich Eckhardt, Jan 4, 2012
  8. 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.

    They represent the terminating nulls of null-terminated strings.

    [windows.h] does not IMHO define any better, more readable name for

    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.


    - ALf
    Alf P. Steinbach, Jan 4, 2012
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.