C++ 😁😁

  • 18
    First way here, because the * is part of the type not the name.
  • 5
    Objective-C too!

    I prefer the first form for the reasons mentioned (pointer-to-Class is a different type than Class), but technically the second form is the official way to do it. The * actually technically modifies the variable.

    It's the same way that you can reference the address of a variable with &var and dereference a pointer with *var.
  • 6
    int *a, *b;
    int* a, * b;

    In the end, the compiler removes the whitespaces anyway ¯\_(ツ)_/¯
  • 6
    @knicklux That's the example I was trying to think of as to why the second form is technically correct: if the * were actually applied to the type you could say this:

    Class* pointer1, pointer2;

    …but pointer2 above is actually of type `Class`. That said I discourage using commas to define multiple variables. I find it sloppy and lazy.
  • 0
    @knicklux So you're telling me to write int*a,*b,*c;for(i=0;i<10;i++){etc?
  • 2
    @bittersweet Don't joke. I inherited a codebase that looks just like that. 😒

    Well ok it had newlines, but he would only use spaces when he absolutely had to.
  • 5
    Second way because of this:
    int* a,b; //worst way to declare an int and a pointer to int
    If you are sleepy ,tired or on desperate debugging mode you may think that b is actually a pointer to int!
  • 0
    @bittersweet Nah, still too high level, I suggest to directly write in LLVM LLIR ;P
  • 0
    Type* p_variableName;
  • 0
    What about now:
    const int *const px = &y;
  • 1
    Syntax highlighter likes the 2nd way
  • 3
    Most standards, including ISO/IEC14882, JSF AV ( joint strike forces air vehicles ), Google's, HIC++ (HIGH INTEGRITY C++), and Bjarn's either discourage or disallow multiple, after-comma declarations of variables. Those are harder to read, and easier to make mistakes with those. Technical language specifications also are written one declaration at the time.

    Second, imo, pointer/reference descriptors are type descriptors not name modifiers.
    uint32_t * label; //or
    uint32_t* label.
    That literally is read as "type's pointer named xxx"
    Exception is dereference where you do *label, read as "de-pointer whatever label is holding"
  • 4
    @edwrodrig actually wrong.
    The pointer is part of the name,
    int *a, b, *c; // a pointer, b int, c pointer
    If it is part of the type you could just write:
    int* a,b,c; // and all would be pointers!
  • 1
    This is bad coding. While a viable option, comma separated declarations are discouraged. Read standards and/or guides, and my comment above
  • 1
    I think making the pointer a const pointer is clearer when using the second syntax, that's where it really shines.
  • 1
    @esavier I am not arguing with you at that one. I was just pointing the syntax. Myself using the first one. But then as @devmg said, that syntax is necessary evil to make those things. Or you can use typedefs. Tho I prefer to use smart pointers.
  • 1

    bool* ok;

    It's type is a Boolean pointer - it has nothing to do with it's name. :)
  • 1
    This format is made only to solve that one problem, so it's special case of declaration. Now follow guidelines and don't use multi declarations, what's left is how user is reading those. And officially there is right-to-left-fold reading pattern for almost everything in c++

    This is weak argument but If users start to memorize that * is a part of name, it's usually ending like this:

    * dupa() ;

    Also take arguments in functions, it's valid to do:
    void dupa( int* );

    Because * is type modifier (descriptor) not name's. "const" is descriptors descriptor,

    @edwrodrig was right there.

    About pointers @devmg
    You read that as "integer constant" not "constant integer", relatively in English you ask "<what> constant" not "constant <what>".
    Proper way to init uint constant's pointer constant is:
    uint32_t const * const a = &what;
    even better,
    uint32_t const * const a { &what } ;
    but not
    uint32_t const * const a = { &what } ;
  • 0
    ...and the parser rolls its eyes at both while it continues slurping up lexemes.
  • 0
    @esavier nice! What is the second type of constructor called? A move constructor?
  • 1
    @esavier I always thought of reading it backwards actually "constant pointer to integer constant"
  • 1
    Second constructor? This with brackets? Those are initializer lists, copy list initialization ( x = { } ) and direct list initialization ( better, x { } ), also there is aggregate initialization but it's usualy for vectors and lists likes, or for complex classes. I believe it is valid since either c++11 or c++14 but not sure which. Also some fun stuff is added for those since c++17.
  • 1
    @esavier ahh, thanks! Direct list initialization is the one I didn't know about.
  • 1
    Use it rather than copy one, it's q
    Kid of quirky in few cases
  • 1
    @esavier running this over node tomorrow then: code.replace(/=\s({. *})/g, (_, cg) => cg)
    Never learnt the VIM way... :P
  • 1
    Yeah but be careful, I am not sure it will work with 100% cases. Try to search stack overflow for those, I saw a good explanation there.

    I dont know vim :9
    Emacs or sed+bash only !
    This is some kind of IDE's options?
  • 1
    @esavier it's just plain javascript, I don't know if you can access the code like that in any IDE. So yeah, I'll have to read the files too. I recently started my project so I'm only glad if anything breaks. Then I can fix it.
Add Comment