GoingNative 36++: CPMD Demo

Sign in to queue

The Discussion

  • User profile image
    Matt

    Looks cool guys. I noticed that the install menu at the beginning of the video mentions iOS Support, but that none of the project templates or shared library features mention it again. Is iOS support planned?

  • User profile image
    gha11

    It is planned, indeed (there's a similarly brief reference to it in the main video =P).

  • User profile image
    Matt_PD

    Looks interesting!

    One quick comment on the automatically generated "main.cpp" code:

    Please consider getting rid of the `struct engine engine; memset(&engine, 0, sizeof(engine));` part -- and instead please consider replacing it with `struct engine engine = {0}` (there are more fixes, but this one is a no-tradeoffs, low hanging fruit).

    Two-stage initialization is an error-prone bad practice -- so is using `memset` to 0-initialize a given data structure (even if it happens to be a POD):

    http://stackoverflow.com/questions/10788861/is-memsetmystruct-0-sizeof-mystruct-same-as-mystruct-0

    Also, since it's "main.cpp" (and not "main.c"), it would probably be even more preferable to use `engine engine;` and add default ctor (if it's even necessary; perhaps its data members are already value-initialized?) to the `engine` struct itself. Attempting to write C++ code as if there was an option to be backward compatible with C (which hasn't really been realistic since the late 1980s, when the languages diverged permanently -- today there's no going back) is a recipe for disaster :(

    Other than potentially lower performance, right now the `memset` code only works by luck -- i.e., only if the `struct` happens to be a generalized POD: https://isocpp.org/wiki/faq/cpp11-language-types#generalized-pods

    Overall, this is also preferred in C -- here's some more detailed information: http://www.codepolice.org/c/memset.html

    Perhaps encouraging relying on luck (even if it just so happens that `engine` remaining a POD is a set-in-stone design invariant that will be guaranteed in the API forever) shouldn't be encouraged in the automatically generated code every developer will rely on from the start?

    Please also consider replacing `NULL` with `nullptr`; here's why: https://isocpp.org/wiki/faq/cpp11-language#nullptr

    Last but not least: please note that I don't mean for any of this to sound harsh; only giving a heads-up that this lack of attention to detail and code quality doesn't give the best impression and detracts from the value of what may otherwise be a really good product! :)

     

  • User profile image
    gha11

    @Matt_PD: Thanks for the feedback! I passed along your comments when you posted it (just neglected to acknowledge >.<)

Add Your 2 Cents