Page 1 of 2 12 LastLast
Results 1 to 10 of 12

Thread: Can't #define ushort

  1. #1
    Join Date
    Aug 2012
    Beans
    185

    Can't #define ushort

    Hi,
    I define this:
    #define ushort unsigned short

    in shared.h and when I include it in a class header like this:

    //class Server.h
    #include "shared.h"
    ...
    ushort port;

    I get errors when trying to compile:

    make
    [ 25%] Building CXX object CMakeFiles/ufbio.dir/Server.cpp.o
    In file included from /usr/include/stdlib.h:320:0,
    from /media/docs/dev/ufbio/Server.cpp:4:
    /usr/include/x86_64-linux-gnu/sys/types.h:152:1: error: duplicate ‘unsigned’
    /usr/include/x86_64-linux-gnu/sys/types.h:152:1: error: duplicate ‘short’
    /usr/include/x86_64-linux-gnu/sys/types.h:152:28: error: declaration does not declare anything [-fpermissive]
    make[2]: *** [CMakeFiles/ufbio.dir/Server.cpp.o] Error 1
    make[1]: *** [CMakeFiles/ufbio.dir/all] Error 2
    make: *** [all] Error 2
    What am I doing wrong?


    EDIT: for some reason including <sys/types.h> after including "shared.h" causes these errors.
    Last edited by bird1500; September 3rd, 2012 at 06:41 AM.

  2. #2
    Join Date
    Aug 2011
    Location
    47°9′S 126°43W
    Beans
    2,172
    Distro
    Ubuntu 16.04 Xenial Xerus

    Re: Can't #define ushort

    Quote Originally Posted by bird1500 View Post
    Hi,
    I define this:
    #define ushort unsigned short

    in shared.h and when I include it in a class header like this:

    //class Server.h
    #include "shared.h"
    ...
    ushort port;

    I get errors when trying to compile:

    What am I doing wrong?


    EDIT: for some reason including <sys/types.h> after including "shared.h" causes these errors.
    Maybe that should be a typedef and not a #define anyway.

  3. #3
    Join Date
    Aug 2012
    Beans
    185

    Re: Can't #define ushort

    Quote Originally Posted by ofnuts View Post
    Maybe that should be a typedef and not a #define anyway.
    Thanks, I have completely forgotten about typedef. As far as I understand, typedef is basically a better #define.

  4. #4
    Join Date
    Feb 2009
    Beans
    1,469

    Re: Can't #define ushort

    Quote Originally Posted by bird1500 View Post
    Hi,
    I define this:
    #define ushort unsigned short
    For the love of $deity, WHY?

    I agree that the feature you really want is typedef, but why would you want to typedef a built-in type WITH A SLIGHTLY SHORTER VERSION OF THE SAME NAME?

    While you're at it, why don't you

    Code:
    typedef int i;
    typedef char c;
    typedef short s;
    ...
    And since that's so repetitive, maybe we can make it even shorter and less readable:

    Code:
    #define t typedef
    t int i;
    t char c;
    ...
    Oh, while we're at it, why don't we throw in some extra #defines, you know, just to save keystrokes:

    Code:
    #define f for
    #define w while
    #define p printf
    Sorry to be rude, but unless your goal is to make C look like APL, why don't you use the names that are provided?

  5. #5
    Join Date
    Aug 2012
    Beans
    185

    Re: Can't #define ushort

    To me "ushort" is much shorter than "unsigned short", just as "uint" is much shorter than "unsigned int".
    Vala and D did the same thing, there's also gnu's guchar, so it's hardly a pedantic idea.

  6. #6
    Join Date
    Feb 2009
    Beans
    1,469

    Re: Can't #define ushort

    Quote Originally Posted by bird1500 View Post
    To me "ushort" is much shorter than "unsigned short", just as "uint" is much shorter than "unsigned int".
    Conciseness is a poor excuse for making code more complex and less readable.
    Vala and D did the same thing, there's also gnu's guchar, so it's hardly a pedantic idea.
    Vala and D are different languages from C and are free to name their types however they want. As for GLib's basic types, well, I can think of one or two weak justifications for why they would do that, but "so-and-so did it" is an equally poor excuse for typedef abuse. Justify yourself, don't point to what other people did.

  7. #7
    Join Date
    Aug 2012
    Beans
    185

    Re: Can't #define ushort

    Quote Originally Posted by trent.josephsen View Post
    Conciseness is a poor excuse for making code more complex and less readable.


    Vala and D are different languages from C and are free to name their types however they want. As for GLib's basic types, well, I can think of one or two weak justifications for why they would do that, but "so-and-so did it" is an equally poor excuse for typedef abuse. Justify yourself, don't point to what other people did.
    It doesn't matter if Vala and D are different languages - you don't get the point, and I can do with C++ whatever I want cause C++ is no less "free" than Vala and D, and it certainly doesn't have to obey your angry pedantic dogmas. And I don't care if you like it or not, trust me, I don't care what is more readable to you, just like the gnu/Vala/D/whatever folks did - we don't care about random people ranting around. If you're in a bad mood take a hike, but don't try teaching us about your naive worldview.

  8. #8
    Join Date
    Feb 2009
    Beans
    1,469

    Re: Can't #define ushort

    ...

  9. #9
    Join Date
    Aug 2011
    Location
    47°9′S 126°43W
    Beans
    2,172
    Distro
    Ubuntu 16.04 Xenial Xerus

    Re: Can't #define ushort

    Quote Originally Posted by bird1500 View Post
    I don't care what is more readable to you, just like the gnu/Vala/D/whatever folks did - we don't care about random people
    Just love that "we"...

  10. #10
    Join Date
    May 2007
    Beans
    251

    Re: Can't #define ushort

    Quote Originally Posted by bird1500 View Post
    Hi,
    I define this:
    #define ushort unsigned short

    in shared.h and when I include it in a class header like this:

    //class Server.h
    #include "shared.h"
    ...
    ushort port;

    I get errors when trying to compile:

    What am I doing wrong?


    EDIT: for some reason including <sys/types.h> after including "shared.h" causes these errors.
    That's because they're already typedefed in <sys/types.h>

    You're not the only one with this requirement - standard C library has had a lot of lazy users already

    I'd rather trust the standard libraries because their designers are a lot more careful in writing portable code
    The Unforgiven

Page 1 of 2 12 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •