Re: The start of a C/C++ adventure...

Discussion in 'C++' started by Jorgen Grahn, Jul 9, 2013.

  1. Jorgen Grahn

    Jorgen Grahn Guest

    On Tue, 2013-07-09, Qu0ll wrote:
    > I have been programming (mainly) in Java for a number of years but am now
    > about to embark on an adventure in C/C++.


    Side note: try to avoid the phrase "C/C++" since it annoys a lot of
    people. To me it sounds like lumping two very different languages
    together, and implying they're pretty much the same.

    > I found that Java was very suitable for most of the applications I have been
    > developing and, contrary to popular belief, very fast in most circumstances.
    > For my server-side work I will still use Java as the principle language of
    > choice on the basis of the language itself, the productivity of tightly
    > integrated IDEs, the plethora of build/test tools, the vast standard library
    > of classes and also the even "vaster" array of 3rd-party libraries that are
    > available. But I have found one usage scenario where Java is just not going
    > to cut it...
    >
    > That is, the UI.

    ....
    > So, what do I choose then? Well, after researching the various options I
    > have decided that the *only* language/platform that seems to be truly
    > portable (in one way or another) is C/C++ and so I am going to devote a
    > large amount of effort and resources into learning this language(s) and the
    > associated ecosystem.


    ....

    > Armed with the answer to question (1), I would like to then look at the best
    > compilers and tools. For Windows the general buzz is that Visual C++ (and I
    > would go straight to VS 2012 or even 2013) seems the best environment and
    > compiler. For Linux it looks like I would have to use GCC and perhaps
    > Eclipse. For MacOS and iOS it looks like clang through XCode but I am not
    > sure what is available on Android.


    Step back for a moment and answer this: are you /really/ going to
    write a program that's portable to Windows, Linux (and other Unixes I
    assume), MacOS, iOS and Android? All at once? Will you also use it
    on all of these platforms (using languages and APIs you're not
    familiar with?) Support users on all of them?

    Portability is nice and everything, but it's a major undertaking.

    Not just the low-level programming, but things like packaging,
    providing documentation and a user interface which makes each group of
    users happy, and so on. Even /knowing/ what makes e.g. MacOS users
    happy can be tricky if you've never met one.

    (Perhaps you know this already and are prepared to pay the price.
    Perhaps you have paying customers already on all platforms?)

    > 2. What are the best compilers/IDEs and tools for the various platforms and
    > is it possible to reuse some of the compilers or tools across multiple
    > platforms? For example, I know Eclipse runs on most platforms but I am not
    > sure of the quality of the CDT tools it embodies.


    As an Emacs user I feel obliged to say it runs everywhere, always has,
    always will. (2) would be a no-brainer for me.

    (No intention to start an IDE/editor flamewar here. Yes, I know there
    are people who feel IDEs are worthwhile.)

    > Next I want to investigate issues surrounding the build pipeline, in
    > particular build and CI tools. For Java I have used Ant, Maven and (lately)
    > Gradle but for C/C++ the common ones seem to be good-old "make" and a now
    > CMake so my next question is:
    >
    > 7. What are the best build tools for C/C++ development that support
    > cross-platform development, ideally being able to build native executables
    > for as many platforms as possible on one single platform?


    Another example of the hidden cost of portability. I use Gnu Make
    exclusively and am very happy with it, but I suspect that restricts me
    to Linux and other Unixes -- which is fine since that's the only
    platform I use and have access to.

    I have tried, and failed, to understand CMake. Do not assume it's the
    modern replacement of Make which everyone uses; it doesn't seem
    exceedingly widely spread, in the Unix world at least.

    > Then there is the issue of unit testing. Obviously for Java the most common
    > tool is JUnit and I believe there is also a CPPUnit so my next question is:
    >
    > 8. What are the best unit testing tools, preferably ones that integrate well
    > with IDEs or tools in (2) and (7) and that provide such feedback as coverage
    > reports etc.?


    The only one I've been really happy with is the one I wrote myself,
    <https://github.com/kjgrahn/testicle>, but that is in itself perhaps
    an indication that most people want something more complicated ...

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Jul 9, 2013
    #1
    1. Advertising

  2. Jorgen Grahn

    James Kanze Guest

    On Tuesday, 9 July 2013 21:16:29 UTC+1, Jorgen Grahn wrote:
    > On Tue, 2013-07-09, Qu0ll wrote:


    > ...
    > > So, what do I choose then? Well, after researching the various options I
    > > have decided that the *only* language/platform that seems to be truly
    > > portable (in one way or another) is C/C++ and so I am going to devote a
    > > large amount of effort and resources into learning this language(s) and the
    > > associated ecosystem.

    > ...
    > > Armed with the answer to question (1), I would like to then look at the best


    > > compilers and tools. For Windows the general buzz is that
    > > Visual C++ (and I would go straight to VS 2012 or even 2013)
    > > seems the best environment and compiler. For Linux it looks
    > > like I would have to use GCC and perhaps Eclipse. For MacOS
    > > and iOS it looks like clang through XCode but I am not sure
    > > what is available on Android.


    [...]
    > > 2. What are the best compilers/IDEs and tools for the
    > > various platforms and is it possible to reuse some of the
    > > compilers or tools across multiple platforms? For example,
    > > I know Eclipse runs on most platforms but I am not sure of
    > > the quality of the CDT tools it embodies.


    > As an Emacs user I feel obliged to say it runs everywhere, always has,
    > always will. (2) would be a no-brainer for me.


    You can say the same for vim. (I suspect that the difference
    between emacs and vim is which one you know best. And perhaps
    the keyboards you have to use: I find that long stretches of
    emacs make my hands hurt, because of the awkward combination of
    keys I have to hit simultaneously. Perhaps a better keyboard
    would solve that.)

    > > Next I want to investigate issues surrounding the build
    > > pipeline, in particular build and CI tools. For Java I have
    > > used Ant, Maven and (lately) Gradle but for C/C++ the common
    > > ones seem to be good-old "make" and a now CMake so my next
    > > question is:


    > > 7. What are the best build tools for C/C++ development that
    > > support cross-platform development, ideally being able to
    > > build native executables for as many platforms as possible
    > > on one single platform?


    > Another example of the hidden cost of portability. I use Gnu Make
    > exclusively and am very happy with it, but I suspect that restricts me
    > to Linux and other Unixes -- which is fine since that's the only
    > platform I use and have access to.


    I use GNU make exclusively too, at least for my own code.
    Including my developments under Windows.

    Like most powerful tools (e.g. emacs or vim), the learning curve
    can be steep. It pays off in the end, however.

    --
    James
    James Kanze, Jul 10, 2013
    #2
    1. Advertising

  3. Jorgen Grahn

    James Kanze Guest

    On Saturday, July 13, 2013 11:45:29 AM UTC+1, Jorgen Grahn wrote:
    > On Wed, 2013-07-10, James Kanze wrote:
    > > On Tuesday, 9 July 2013 21:16:29 UTC+1, Jorgen Grahn wrote:
    > >> On Tue, 2013-07-09, Qu0ll wrote:


    > ...


    > >> As an Emacs user I feel obliged to say it runs everywhere, always has,
    > >> always will. (2) would be a no-brainer for me.


    > > You can say the same for vim.


    > Yes; I could have written "one of the ever-present powerful text
    > editors" instead of "Emacs". The conflict between Emacs and Vim users
    > is mostly a game; we never get in each other's way.


    Are there any other editors which are powerful enough to be
    really useful. Every really good C++ programmer I've known uses
    either vim or emacs; is it pure chance, or is there some sort of
    relationship?

    > ...


    > >> > 7. What are the best build tools for C/C++ development that
    > >> > support cross-platform development, ideally being able to
    > >> > build native executables for as many platforms as possible
    > >> > on one single platform?


    > >> Another example of the hidden cost of portability. I use Gnu Make
    > >> exclusively and am very happy with it, but I suspect that restricts me
    > >> to Linux and other Unixes -- which is fine since that's the only
    > >> platform I use and have access to.


    > > I use GNU make exclusively too, at least for my own code.
    > > Including my developments under Windows.


    > > Like most powerful tools (e.g. emacs or vim), the learning curve
    > > can be steep. It pays off in the end, however.


    > Partly disagree: learning to use Make is more about getting a few
    > basic ideas behind the language (like providing a complete list of
    > dependencies) and learning how to apply them in common situations.


    The basic rules for make are simple. Getting it to
    automatically generate dependencies, handle different systems
    and build types, etc., can require some deeper knowledge. (GNU
    make is Turing complete, so you can do anything in it. Not
    easily, however, and some things can end up pretty hairy.)

    > Or rather, the learning curve /is/ steep, but short. With text
    > editors it's long instead: I learn new, practical Emacs things after
    > 20 years of use. Same as C++ ...


    And vim. Agreed.

    --
    James
    James Kanze, Jul 13, 2013
    #3
  4. Jorgen Grahn

    Balog Pal Guest

    On 7/13/2013 3:20 PM, James Kanze wrote:

    > Are there any other editors which are powerful enough to be
    > really useful. Every really good C++ programmer I've known uses
    > either vim or emacs; is it pure chance, or is there some sort of
    > relationship?


    Yeah, the relationship is created by your sampling methods and
    associated filters. ;-)

    I for example don't use any of those. In the last heavy vim-using
    environment the best C++ programmer used joe. Those working for
    non-unix would puke from any vi-descendant, and for emacs you'd need a
    kind of accident.

    And certainly we know that it's not the editor that makes a programmer
    good but the gray matter. ;-)
    Balog Pal, Jul 15, 2013
    #4
  5. Jorgen Grahn

    Stuart Guest

    On 07/15/13, Balog Pal wrote:
    > On 7/13/2013 3:20 PM, James Kanze wrote:
    >
    >> Are there any other editors which are powerful enough to be
    >> really useful. Every really good C++ programmer I've known uses
    >> either vim or emacs; is it pure chance, or is there some sort of
    >> relationship?

    >
    > Yeah, the relationship is created by your sampling methods and
    > associated filters. ;-)
    >
    > I for example don't use any of those. In the last heavy vim-using
    > environment the best C++ programmer used joe. Those working for
    > non-unix would puke from any vi-descendant, and for emacs you'd need a
    > kind of accident.
    >
    > And certainly we know that it's not the editor that makes a programmer
    > good but the gray matter. ;-)


    I disagree partially. I tend to use very verbose names, like those:

    CTiltAxis (CAxis* AxisA,
    CAxis* AxisB,
    CAxis* AxisC,
    CAxis* LateralCompensationAxis,
    double AngleOfPointA,
    double DiameterOfMotorCircleInMillimeters,
    const char* strAxisName);

    I would hate to use variable names like
    "DiameterOfMotorCircleInMillimeters" if I had no support from my IDE (MS
    Visual Studio in that case). Other programmers in my department tend to
    write code like this:

    [np np nz] = size(imstack);
    z = zeros(np,np,1);

    That is due to the fact that they have to use Matlab, and apparently
    Matlab offers no code completion. "imstack" should actually be something
    like "imageStack". This is as verbose as their code ever gets. Try to
    figure out what this parameter list means:
    function [np,imagin,ipsfin,rmsz,corrz,xsz,ysz,dpinorm,jgew,iphfit,nactiv]

    Regards,
    Stuart

    PS: The code I have posted is actually from real production systems, no
    fake. I hope that none of my former co-workers read this ;-)
    Stuart, Jul 16, 2013
    #5
  6. Jorgen Grahn

    Jorgen Grahn Guest

    On Tue, 2013-07-16, Stuart wrote:
    > On 07/15/13, Balog Pal wrote:
    >> On 7/13/2013 3:20 PM, James Kanze wrote:
    >>
    >>> Are there any other editors which are powerful enough to be
    >>> really useful. Every really good C++ programmer I've known uses
    >>> either vim or emacs; is it pure chance, or is there some sort of
    >>> relationship?

    >>
    >> Yeah, the relationship is created by your sampling methods and
    >> associated filters. ;-)
    >>
    >> I for example don't use any of those. In the last heavy vim-using
    >> environment the best C++ programmer used joe. Those working for
    >> non-unix would puke from any vi-descendant, and for emacs you'd need a
    >> kind of accident.
    >>
    >> And certainly we know that it's not the editor that makes a programmer
    >> good but the gray matter. ;-)

    >
    > I disagree partially. I tend to use very verbose names, like those:
    >
    > CTiltAxis (CAxis* AxisA,
    > CAxis* AxisB,
    > CAxis* AxisC,
    > CAxis* LateralCompensationAxis,


    (Hm, not const CAxis& ?)

    > double AngleOfPointA,
    > double DiameterOfMotorCircleInMillimeters,
    > const char* strAxisName);
    >
    > I would hate to use variable names like
    > "DiameterOfMotorCircleInMillimeters" if I had no support from my IDE (MS
    > Visual Studio in that case).


    Completion of long words is indeed extremely useful (I wouldn't use an
    editor without it), but it's also widely implemented. Even JED (the
    editor I only use for Usenet and mail) has it.

    > Other programmers in my department tend to
    > write code like this:
    >
    > [np np nz] = size(imstack);
    > z = zeros(np,np,1);
    >
    > That is due to the fact that they have to use Matlab, and apparently
    > Matlab offers no code completion. "imstack" should actually be something
    > like "imageStack". This is as verbose as their code ever gets. Try to
    > figure out what this parameter list means:
    > function [np,imagin,ipsfin,rmsz,corrz,xsz,ysz,dpinorm,jgew,iphfit,nactiv]


    (It's a slightly unfair comparison since it's not C++ -- the types are
    missing. If it's Matlab, perhaps there is no good support for
    user-defined types either, and that's why there are so many
    parameters?)

    It all depends very much on what style you're trained to like, and/or
    how your mind works.

    I'm personally more on your coworkers' side. In particular I dislike
    encoding type information into names, so:

    CAxis* AxisA
    Axis* AxisA // useless 'C' prefix (from a non-Microsoft perspective)
    Axis* A // trust the type
    Axis* a // I prefer leading lowercase in variable names

    For these ones:

    double AngleOfPointA
    double DiameterOfMotorCircleInMillimeters

    - I have a feeling the "OfMotorCircle" part is obvious from context,
    when you know the context -- e.g. that the whole point of CTiltAxis is
    to do something to a motor circle.

    - The "InMillimeters" part is to me a sign that your typing is too
    weak; if you really must juggle several different length units, you
    might be better off having distinct types for lengths in
    millimeters, meters and inches, or whatever. (Note that I'm not
    saying it's always worth it.)

    - Same with "Angle".

    But that's just how /my/ mind works. I tend to increase (subjective)
    readability by removing non-essential and duplicate information.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Jul 16, 2013
    #6
  7. Jorgen Grahn

    Ian Collins Guest

    Jorgen Grahn wrote:
    >
    > I'm personally more on your coworkers' side. In particular I dislike
    > encoding type information into names, so:
    >
    > CAxis* AxisA
    > Axis* AxisA // useless 'C' prefix (from a non-Microsoft perspective)


    It is amusing when someone who likes an IDE with intellisense that can
    tell you what a type is still uses that strange (to a non-windows
    programmer) style..

    --
    Ian Collins
    Ian Collins, Jul 16, 2013
    #7
  8. Jorgen Grahn

    Öö Tiib Guest

    On Tuesday, 16 July 2013 11:10:58 UTC+3, Ian Collins wrote:
    > Jorgen Grahn wrote:
    > >
    > > I'm personally more on your coworkers' side. In particular I dislike
    > > encoding type information into names, so:
    > >
    > > CAxis* AxisA
    > > Axis* AxisA // useless 'C' prefix (from a non-Microsoft perspective)

    >
    > It is amusing when someone who likes an IDE with intellisense that can
    > tell you what a type is still uses that strange (to a non-windows
    > programmer) style..


    Actually I have always thought that the "C" is in Microsofts AFX/MFC was
    meant as prefix for the library classes not suggested naming style
    for application classes. Since lot of frameworks had their ground laid
    before namespaces we have them (like "Q" in Qt or "wx" in wxWidgets).

    So it feels a bit like name in wrong namespace (no CAxis in MS
    frameworks). Sometimes that strange style can amuse with some funny
    name (like "CUntangled") when applied to application classes.
    Öö Tiib, Jul 16, 2013
    #8
  9. Jorgen Grahn

    James Kanze Guest

    On Monday, 15 July 2013 22:30:26 UTC+1, Balog Pal wrote:
    > On 7/13/2013 3:20 PM, James Kanze wrote:


    > > Are there any other editors which are powerful enough to be
    > > really useful. Every really good C++ programmer I've known uses
    > > either vim or emacs; is it pure chance, or is there some sort of
    > > relationship?


    > Yeah, the relationship is created by your sampling methods and
    > associated filters. ;-)


    Could be. Until a couple of years ago, I had only worked in
    Unix environments (at least since the mid-1980's), so "every
    really good C++ programmer used either vim or emacs", because
    "every programmer used either vim or emacs". For the last three
    and half years, however, I have worked in a Windows environment,
    and the very best programmers there also used vim or emacs. But
    it's an extremely small sampling (and some pretty good
    programmers did use the VS editor).

    > I for example don't use any of those. In the last heavy vim-using
    > environment the best C++ programmer used joe. Those working for
    > non-unix would puke from any vi-descendant,


    I'm currently working in a 100% Windows environment, and I use
    vim.

    > and for emacs you'd need a kind of accident.


    > And certainly we know that it's not the editor that makes a programmer
    > good but the gray matter. ;-)


    Yes, but good gray matter will affect how you chose an editor.

    An interesting side-light: the people I know who prefer vim,
    even in a Windows enviroment, all touch type. None of the
    people I know who prefer the VS editor touch type. I don't know
    what conclusion to draw from that, though.

    (Another co-relation, at least in people I know: programmers who
    prefer vim or emacs tend to make heavy use of regular
    expressions and external tools. Those who use VS tend to do
    everything in VS.)

    --
    James
    James Kanze, Jul 16, 2013
    #9
  10. Jorgen Grahn

    James Kanze Guest

    On Tuesday, 16 July 2013 09:10:58 UTC+1, Ian Collins wrote:
    > Jorgen Grahn wrote:


    > > I'm personally more on your coworkers' side. In particular I dislike
    > > encoding type information into names, so:


    > > CAxis* AxisA
    > > Axis* AxisA // useless 'C' prefix (from a non-Microsoft perspective)


    > It is amusing when someone who likes an IDE with intellisense that can
    > tell you what a type is still uses that strange (to a non-windows
    > programmer) style..


    It depends. Where I currently work, we use one letter prefixes:
    B for basic classes, S for structs (which reveal all of their
    data) T for class templates, G for namespaces and A for (machine
    generated) archive classes. I was against it at the start, but
    in practice, it seems to actually be useful: I'd add I for pure
    interfaces and F for functional objects, however.

    It also means that class names start with two capital letters,
    which allows them to be differentiated from function names.
    (I was against starting function names with a capital letter,
    since this meant that they couldn't be distinguished from class
    names. And distinguishing them from class names was more
    important than distinguishing them from variables. But with the
    above conventions for classes, etc., there's no real problem.)

    And intellisense doesn't tell you whether a class has all data
    members public, or only pure virtual functions and no data.

    --
    James
    James Kanze, Jul 16, 2013
    #10
  11. Jorgen Grahn

    Ian Collins Guest

    James Kanze wrote:
    > On Tuesday, 16 July 2013 09:10:58 UTC+1, Ian Collins wrote:
    >> Jorgen Grahn wrote:

    >
    >>> I'm personally more on your coworkers' side. In particular I dislike
    >>> encoding type information into names, so:

    >
    >>> CAxis* AxisA
    >>> Axis* AxisA // useless 'C' prefix (from a non-Microsoft perspective)

    >
    >> It is amusing when someone who likes an IDE with intellisense that can
    >> tell you what a type is still uses that strange (to a non-windows
    >> programmer) style..

    >
    > It depends. Where I currently work, we use one letter prefixes:
    > B for basic classes, S for structs (which reveal all of their
    > data) T for class templates, G for namespaces and A for (machine
    > generated) archive classes. I was against it at the start, but
    > in practice, it seems to actually be useful: I'd add I for pure
    > interfaces and F for functional objects, however.
    >
    > It also means that class names start with two capital letters,
    > which allows them to be differentiated from function names.
    > (I was against starting function names with a capital letter,
    > since this meant that they couldn't be distinguished from class
    > names. And distinguishing them from class names was more
    > important than distinguishing them from variables. But with the
    > above conventions for classes, etc., there's no real problem.)


    That's a bit like the logic for introducing cane toads into Australia...

    > And intellisense doesn't tell you whether a class has all data
    > members public, or only pure virtual functions and no data.


    But in practice, do you care? I would expect VS to be like NetBeans (my
    current IDE) and only offer members accessible in the current context.

    --
    Ian Collins
    Ian Collins, Jul 16, 2013
    #11
  12. Jorgen Grahn

    Ian Collins Guest

    James Kanze wrote:
    > On Monday, 15 July 2013 22:30:26 UTC+1, Balog Pal wrote:
    >
    >> And certainly we know that it's not the editor that makes a programmer
    >> good but the gray matter. ;-)

    >
    > Yes, but good gray matter will affect how you chose an editor.


    Not really. How the grey matter ticks will affect how you chose an editor.

    --
    Ian Collins
    Ian Collins, Jul 16, 2013
    #12
  13. Jorgen Grahn

    ptyxs Guest

    Le 13/07/2013 15:20, James Kanze a écrit :
    > Are there any other editors which are powerful enough to be
    > really useful. Every really good C++ programmer I've known uses
    > either vim or emacs; is it pure chance, or is there some sort of
    > relationship?
    >


    Probably QtCreator (even not programming with Qt), don't you think so ?

    ptyxs
    ptyxs, Jul 16, 2013
    #13
  14. Jorgen Grahn

    Stuart Guest

    On 07/16/13, Ian Collins wrote:
    > Jorgen Grahn wrote:
    >>
    >> I'm personally more on your coworkers' side. In particular I dislike
    >> encoding type information into names, so:
    >>
    >> CAxis* AxisA
    >> Axis* AxisA // useless 'C' prefix (from a non-Microsoft perspective)

    >
    > It is amusing when someone who likes an IDE with intellisense that can
    > tell you what a type is still uses that strange (to a non-windows
    > programmer) style..


    Well, I just copied the style from MFC (yes, spare me the laughter). I
    find the following code more readable then the one after it:

    class CMySpecialWindow : public CWnd {
    protected:
    CString m_strMyVariable;

    public:
    CMySpecialWindow () : CWnd ()
    {
    m_hWnd = 0;
    m_strMyVariable = "";
    }
    };

    in constrast to:

    class MySpecialWindow : public CWnd {
    protected:
    CString myVariable;

    public:
    MySpecialWindow () : CWnd ()
    {
    m_hWnd = 0;
    myVariable = "";
    }
    };

    When in Rome, ...

    Of course, nowadays I'm forced to adapt to Java's style because our
    classes must have the same layout on the client (ObjectiveC) as well as
    the server (Java). I recently discovered that method names in ObjectiveC
    must not begin with the string "new" or else Apple's Automatic Reference
    Counting won't work properly. Makes me long for the good old C++ times.
    Any job offers? ;-)

    Regards,
    Stuart
    Stuart, Jul 16, 2013
    #14
  15. Jorgen Grahn

    Öö Tiib Guest

    On Tuesday, 16 July 2013 17:49:16 UTC+3, Stuart wrote:
    >
    > Well, I just copied the style from MFC (yes, spare me the laughter). I
    > find the following code more readable then the one after it:
    >
    > class CMySpecialWindow : public CWnd {
    > protected:
    > CString m_strMyVariable;
    >
    > public:
    > CMySpecialWindow () : CWnd ()
    > {
    > m_hWnd = 0;
    > m_strMyVariable = "";
    > }
    > };
    >
    > in constrast to:
    >
    > class MySpecialWindow : public CWnd {
    > protected:
    > CString myVariable;
    >
    > public:
    > MySpecialWindow () : CWnd ()
    > {
    > m_hWnd = 0;
    > myVariable = "";
    > }
    > };


    Interesting, why? Yes, some people feel same way about Qt or wxWidgets
    with their QMySpecialDialog or wxMySpecialWindow but I do not get it how.
    To me it looks as confusing as std::my_stuff (that is even forbidden
    by standard).

    BTW ... doesn't CWnd's constructor really initialize its 'm_hWnd' itself
    or is that dangerous access just for purpose of example? I vaguely
    remember that writing it directly was always programming error and
    for reading was GetSafeHwnd().
    Öö Tiib, Jul 16, 2013
    #15
  16. Jorgen Grahn

    Stuart Guest

    On 07/16/13, Öö Tiib wrote:
    > On Tuesday, 16 July 2013 17:49:16 UTC+3, Stuart wrote:
    >>
    >> Well, I just copied the style from MFC (yes, spare me the laughter). I
    >> find the following code more readable then the one after it:
    >>
    >> class CMySpecialWindow : public CWnd {
    >> protected:
    >> CString m_strMyVariable;
    >>
    >> public:
    >> CMySpecialWindow () : CWnd ()
    >> {
    >> m_hWnd = 0;
    >> m_strMyVariable = "";
    >> }
    >> };
    >>
    >> in constrast to:
    >>
    >> class MySpecialWindow : public CWnd {
    >> protected:
    >> CString myVariable;
    >>
    >> public:
    >> MySpecialWindow () : CWnd ()
    >> {
    >> m_hWnd = 0;
    >> myVariable = "";
    >> }
    >> };

    >
    > Interesting, why? Yes, some people feel same way about Qt or wxWidgets
    > with their QMySpecialDialog or wxMySpecialWindow but I do not get it how.
    > To me it looks as confusing as std::my_stuff (that is even forbidden
    > by standard).


    Luckily I haven't been in a situation where two libraries with two
    totally contrary coding styles were used.

    > BTW ... doesn't CWnd's constructor really initialize its 'm_hWnd' itself
    > or is that dangerous access just for purpose of example? I vaguely
    > remember that writing it directly was always programming error and
    > for reading was GetSafeHwnd().


    Of course, you remember that right. Although, if my memory serves me
    right, setting m_hWnd to null in the default constructor does no harm.

    Regards,
    Stuart
    Stuart, Jul 16, 2013
    #16
  17. Jorgen Grahn

    Guest

    On Tuesday, July 16, 2013 4:28:13 AM UTC-5, James Kanze wrote:
    >
    > It depends. Where I currently work, we use one letter prefixes:
    > B for basic classes, S for structs (which reveal all of their
    > data) T for class templates, G for namespaces and A for (machine
    > generated) archive classes. I was against it at the start, but
    > in practice, it seems to actually be useful: I'd add I for pure
    > interfaces and F for functional objects, however.


    Are archive classes a Microsoft thing?

    https://duckduckgo.com/?q="archive class"

    Brian
    Ebenezer Enterprises - John 3:16.
    http://webEbenezer.net
    , Jul 16, 2013
    #17
  18. Jorgen Grahn

    Balog Pal Guest

    On 7/16/2013 11:20 AM, James Kanze wrote:

    >> I for example don't use any of those. In the last heavy vim-using
    >> environment the best C++ programmer used joe. Those working for
    >> non-unix would puke from any vi-descendant,

    >
    > I'm currently working in a 100% Windows environment, and I use
    > vim.


    BAH, misphrased, I meant those who started and evolved there. Of course
    you use vim -- that is the editor you used. I used visual studio in unix
    developpment for the very same reason. But it doesn't say anything
    about the editor really, only about our (in)flexibility. ;-)

    >> and for emacs you'd need a kind of accident.

    >
    >> And certainly we know that it's not the editor that makes a programmer
    >> good but the gray matter. ;-)

    >
    > Yes, but good gray matter will affect how you chose an editor.


    How, yes. Which -- will vary all the same. :)

    > An interesting side-light: the people I know who prefer vim,
    > even in a Windows enviroment, all touch type.


    I try to recall people from my past, and just can't find a single one
    who did not touch-type.

    > None of the people I know who prefer the VS editor touch type.


    Hm, I start wondering where the winds blew you this time. ;)

    > I don't know what conclusion to draw from that, though.


    Probably that you're in some weird place. But maybe it's the other way
    around really, and touch-typing is connected more to being aged. And new
    environments with completion work against TT? We have three fresh-grads
    and they type alright, I honestly never thought it's an attribute worth
    checking on interview or something.

    > (Another co-relation, at least in people I know: programmers who
    > prefer vim or emacs tend to make heavy use of regular
    > expressions and external tools. Those who use VS tend to do
    > everything in VS.)


    And what counts "external"? VS has hundreds of plugins, are those in or
    out? How about macros you write or record in emacs or vs?

    What is the virtue of external tool if you get it inside? The most
    frequent one is IME definitely grep -- that was built-in VS from 1.0.
    Along with globalreplace.

    Build/compiler and debugger is inside, so is source control (well,
    mostly). And the bug tracker. Even an internal web browser is
    available. So WHAT is left needed for externalia?

    Well, I'm not happy with the integrated git support so use a plenty of
    it outside, but possibly it will be better covered in a year.

    IMO the practical approach is to look *how problems are solved* and
    whether they are actually. Not the composition of the applied clicks
    and keystrokes. If time is wasted on manual work or workaround what a
    program could just do -- that *is* a problem.
    Balog Pal, Jul 16, 2013
    #18
  19. Jorgen Grahn

    Balog Pal Guest

    On 7/16/2013 11:12 AM, Öö Tiib wrote:
    >>> I'm personally more on your coworkers' side. In particular I dislike
    >>> encoding type information into names, so:
    >>>
    >>> CAxis* AxisA
    >>> Axis* AxisA // useless 'C' prefix (from a non-Microsoft perspective)

    >>
    >> It is amusing when someone who likes an IDE with intellisense that can
    >> tell you what a type is still uses that strange (to a non-windows
    >> programmer) style..

    >
    > Actually I have always thought that the "C" is in Microsofts AFX/MFC was
    > meant as prefix for the library classes not suggested naming style
    > for application classes.


    Not completely, as the wizards in Visual C++ normally pushed you to have
    the C, m_ and other prefixes. Even more the sample programs and example
    from MSDN pages. (along with the systems Hungarian from ther and
    Petzold's books...)

    But just as you, smart programmers did not pick those for unrelated
    stuff with some luck.
    Balog Pal, Jul 16, 2013
    #19
  20. Jorgen Grahn

    Balog Pal Guest

    On 7/16/2013 11:28 AM, James Kanze wrote:
    > On Tuesday, 16 July 2013 09:10:58 UTC+1, Ian Collins wrote:
    >> Jorgen Grahn wrote:

    >
    >>> I'm personally more on your coworkers' side. In particular I dislike
    >>> encoding type information into names, so:

    >
    >>> CAxis* AxisA
    >>> Axis* AxisA // useless 'C' prefix (from a non-Microsoft perspective)

    >
    >> It is amusing when someone who likes an IDE with intellisense that can
    >> tell you what a type is still uses that strange (to a non-windows
    >> programmer) style..

    >
    > It depends. Where I currently work, we use one letter prefixes:
    > B for basic classes, S for structs (which reveal all of their
    > data) T for class templates, G for namespaces and A for (machine
    > generated) archive classes. I was against it at the start, but
    > in practice, it seems to actually be useful: I'd add I for pure
    > interfaces and F for functional objects, however.


    Any convention is good if you play with it consistently. In real world
    applications we tend to use 3rd party components, and those water up any
    convention pretty fast. So my take was always to put it in the
    unregulated territory.

    > It also means that class names start with two capital letters,
    > which allows them to be differentiated from function names.


    That is the part I normally get confused. Why would I want the
    differentiation? The code should read as a good book. There you don;t
    need verbs to get distincted by having two-capital start... ;-)

    > (I was against starting function names with a capital letter,
    > since this meant that they couldn't be distinguished from class
    > names.


    The only context I can think where class names and function names would
    not be obvious (in application code domain) are really constructor calls.

    I didn't write too many templates lately (almost none if we filter out
    chunks under 4 lines length), but even there it sounds like no help.


    And more importantly, the quite basic tools know if something is type or
    a function and applies different coloring. So you can tell them by
    having other color without fiddling with the name. (maybe that's why I'm
    blind to the approach? ;-)

    > And distinguishing them from class names was more
    > important than distinguishing them from variables. But with the
    > above conventions for classes, etc., there's no real problem.)


    Isn't that some vim-related artifact? Can't you set those categories to
    different color/font style?

    > And intellisense doesn't tell you whether a class has all data
    > members public, or only pure virtual functions and no data.


    That's true but why should I ever care?
    Balog Pal, Jul 16, 2013
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. K. Frank
    Replies:
    2
    Views:
    150
  2. Christopher Pisz

    Re: The start of a C/C++ adventure...

    Christopher Pisz, Jul 9, 2013, in forum: C++
    Replies:
    0
    Views:
    147
    Christopher Pisz
    Jul 9, 2013
  3. Öö Tiib
    Replies:
    2
    Views:
    127
    Öö Tiib
    Jul 10, 2013
  4. Andrea Venturoli

    Re: The start of a C/C++ adventure...

    Andrea Venturoli, Jul 10, 2013, in forum: C++
    Replies:
    0
    Views:
    148
    Andrea Venturoli
    Jul 10, 2013
  5. K. Frank
    Replies:
    1
    Views:
    160
    Jorgen Grahn
    Jul 15, 2013
Loading...

Share This Page