• (cs) in reply to Sam LG
    Anonymous:
    Okay, it's mostly annoying, but there's a minor case to be made for the EQ operator -- namely, that it's easy to leave off an '=' by mistake.

    Of course, a better solution to this is, whenever possible, to put one's variables on the *right* side of the == operator, but still, I can almost forgive that one.


    ... which works until you're trying to compare two variables.

    C# will save you by requiring if (...) to have a boolean inside it... which works until you have to test boolean variables.
  • (cs) in reply to Sam LG

    Anonymous:
    Okay, it's mostly annoying, but there's a minor case to be made for the EQ operator -- namely, that it's easy to leave off an '=' by mistake.

    Of course, a better solution to this is, whenever possible, to put one's variables on the *right* side of the == operator, but still, I can almost forgive that one.

    An even better solution... Let the compiler point these out to you. That way you can put the variable on either side (especially useful when BOTH sides need a varuable)

  • ajk (unregistered) in reply to chrismcb

    Well Visual Studio has a standard header called iso646.h

    #include <iso646.h>

    #pragma once
    #ifndef _ISO646
    #define _ISO646

    #if !defined(__cplusplus) || defined(_MSC_EXTENSIONS)
     #define and    &&
     #define and_eq    &=
     #define bitand    &
     #define bitor    |
     #define compl    ~
     #define not    !
     #define not_eq    !=
     #define or        ||
     #define or_eq    |=
     #define xor    ^
     #define xor_eq    ^=
    #endif /* !__cplusplus || _MSC_EXTENSIONS /

    #endif /
    _ISO646 */

    <snip>


  • (cs) in reply to Sam
    Anonymous:

    Oh, it's just personal preference.  He didn't like the syntax, so he changed it.  Big deal.

    If it wasn't a big deal, everyone would use Lisp.

  • thatoneguy (unregistered) in reply to ajk

    #define ENDOFPROGRAMMINGLINE ;

    He forgot a define for the semicolon. That would make your code so much more understandable!

  • (cs) in reply to ZeoS

    ZeoS:
    The real WTF is that there are people still programing in C

    As opposed to.... ....I normally use Python, but it's um, implemented in C (well apart from IronPython and Jython)... so if I want to extend, I have to use C... if I want to write a small fast application, I tend to use C. C++ is overkill 80% of the time.

    ...when I'm working with the Win32 API I prefer to use C for simplicity's sake. What do you use?

  • (cs) in reply to Manni
    Manni:

    Ugh, what a waste. It looks like he's trying to pull in some VB or SQL syntax. That makes sense, because it's so hard to remember ">" should be used for greater-than comparisons. Speaking of which, in a lot of places he replaced an operator (like ">") with a keyword that's longer than the original (now it's "GT").

    I say we send him hunting with Dick Cheney.



    not to mention far more ambiguous!
  • Silex (unregistered) in reply to Cyresse

    <font color="#999999"> if I want to write a small fast application, I tend to use C. C++ is overkill 80% of the time.</font>

    It depends what you call overkill. Most of the time the clarity & convenience offered by C++ outweight the (small) performance lost (if any) compared to C.

  • (cs) in reply to graywh
    wintermyute:
    Sweet.  This is one of the de-facto obfuscation methods used by entrants to the International Obfuscated C Code Contest

    Indeed:

    #define N(I,l) s l]=(I?1<<I|I<<10:01776)
    #define f(a,t) for(a=0;a<t;a++)
    /* cut /
    #define s S].s[l
    /
    cut /
    Su(row,col,box) C=l0=0;
    f(l,81) if(!(s]>>10&&++l0)) {
    o=s]&1022; for(I=0;~o&1&&(o/=2);I++); o-1||(s]|=I<<10,C++);
    } if(l0==l) {
    if(O&&L&2) { O--; goto l0; } goto O;
    } for(l0=1;10>l0;l0++) { Su(,,) }
    /
    cut */


    No, the brackets don't match; it's obviously not WTF-worthy though, since it's deliberate. If you see anything like this in production code, please shoot the programmer ASAP. (No-one would do something like this outside the IOCCC contest - right? Right?)

  • (cs) in reply to Dan
    Anonymous:
    Skinnable programming languages - it's the future. Don't like your current language? Don't want to go to the hassle of writing your own language and compiler? Just pick a language that's close enough and skin it.


    Comeon, you aren't thinking hard enough.  The future is XML programming language, with all the variable names, function names, and operators as their own tag.  The IDE would then be an XML parser, which when opening a file would convert the XML elements into your preselected viewing preference, and convert back to XML on a save.  The interpreter can JIT compile the XML into the byte code of your choice by means of a virtual byte code processor, which can then be interpreted by the VM of your choice.

    Minimum specs for running any program:  Athlon64x8 4000 with 10GB of RAM.
  • (cs) in reply to Silex
    Anonymous:
    <FONT color=#999999> if I want to write a small fast application, I tend to use C. C++ is overkill 80% of the time.</FONT> It depends what you call overkill. Most of the time the clarity & convenience offered by C++ outweight the (small) performance lost (if any) compared to C.


    Sorry, should've been clearer. 80% of the time, C++ would be overkill for the code I'm writing in C. I don't mean to generalise. Normally I'm just stringing together a bunch of Win32 API calls to create some small utility function (like my service turner-on/offer for services I use only occasionally like mysql-nt, because I'm too lazy to open services.msc).

    If I ever am compelled to work on a large project, I would prefer C++ over C any day, I'm too used to OO.

    Beauty of being a hobbyist programmer rather than a professional is that I get to choose what I do my projects in.

    However, afaik, there's some stuff that does require C instead of C++. I've written a couple of kernel side drivers, and C++ is bad there, although I do wish I had the objects to use. Yucky stuff.
  • (cs) in reply to Javariel

    Wow, this is a popular topic. It's a little silly, but something I've done in all my recent C/C++ projects is to use:

    #define REP(x,y,z)              for((x)=(y);(x)<=(z);(x)++)
    #define REPN(x,y,z)             for((x)=(y);(x)<((z)-(y));(x)++)
    #define REPZ(x,z)               for((x)=0;(x)<=(z);(x)++)
    #define REPZN(x,z)              for((x)=0;(x)<(z);(x)++)

    as one of my standard headers. Just because after having used so many other languages (every other language on the planet seems to have a "for each" construct) a codebase full of generic for loops is the ugliest thing on god's green earth besides my neighbor's lawn. And yes, I named them after the asm instructions for very-vague similarity.

    So far I've had more "hey, neat" than "wtf is this, are you insane", so I'd say success. =D

  • Dave (unregistered) in reply to Albatross

    Sadly I've seen this before, but worse. My first job was for a Unix software house in the UK who use CBASIC - yep, C with a ton of macros. Some of the joking posts were closer to the truth. I had to spend a couple of years before I managed to get transferred to the systems team, where we could use C properly.

  • (cs) in reply to R.Flowers
    R.Flowers:

    Yeah, the NE, EQ, etc. are Perly. Then we have MOD, which is VBish.

    What's up with 'forever?' Where was he going to use <FONT face="Courier New">forever{ //do something}</FONT> ?

    Actually, that's not a bad idiom.  The construct while(1) { ... } generates better assembly on a lot of compilers.  You DO have to remember to perform a test and break, of course, but it really does work better.   Sometimes you just need a mid-tested loop.

    Yes, I'm sure some C++ book author named Steve will recommend against this, but hey, it's a free country.

  • (cs) in reply to ZeoS
    ZeoS:
    #define COMMENT // #define macro define #macro . ; COMMENT every statement should finish with .

    Sorry ... The C preprocessor strips out comments before dealing with macros. So, the definition of COMMENT is in fact blank. Although you can use macros in place of C keywords, you can't use them for preprocessor directives.

    So while you could do #define if while it would only affect if (something) { do_stuff(); } and not #if some_macro void do_stuff(void); #endif

  • (cs) in reply to jspenguin

    Oh BTW I posted this yesterday in the Side Bar, but it's relevant to the topic at hand:

    #define _ int
    #define d(c,D,R,Z,F)x,S=1,B=0,O=0,r=1,M=p+E,Q=k,*N=j+f*k,*o=N;p-=E;while(I>=0){x=S<B;c;if(r){if(-1<k&k<u)Z(N,k)if(-1<Q&Q<u)Z(o,Q)F 0;}if(x)++p,--M,S+=I-=D;else k++,Q--,N+=f,o-=f,B+=O+=R,F 1;}}
    #define Y(W,k)0<=p&p<f&&(W[p]=s),0<=M&M<f&&(W[M]=s);
    #define g(W,R,C){_ w=0,C I=E*W,d(r=x==w|!r;w=x,W,R,Y,)
    #define v(W,k){G=p<0?W:W+p;Z=f>M?W+M:W+f;while(G<Z)*G++=s;}
    #define L(W,R,C){_*G,C*Z,I=E*W,d(,W,R,v,r=)
    #define R(n)_ n(_*j,_ f,_ u,_ s,_ p,_ k,_ E,_ e)
    #define a D=e*e,T=E*E,
    R(cr)g(1,1,)R(ov)g(D,T,a)R(fc)L(1,1,)R(fo)L(D,T,a)
    

    Can you guess what it does without reading the description in the Side Bar?

  • (cs) in reply to stonguse
    stonguse:
    Anonymous:

    Oh, it's just personal preference.  He didn't like the syntax, so he changed it.  Big deal.

     

     



    Yeah, things are better off when everyone creates their own syntax.


    Yeah, who's going to maintain the code anyway?  It's perfect the first time, right?
  • (cs) in reply to bramster

    Anonymous:
    I never did like those pesky equal signs anyway.

    #define CURLY_OPEN_BRACE {


    Isn't that just:

    #define BEGIN {
    #define END }

    -shnar

  • (cs) in reply to Manni

    Just write a quick script that reads the stupid header file, creates a look-up table and then goes through the source tree replacing the macro tokens.  Then delete the header file and pretend "better C" never existed.  Should take you less than 2 hours.  Plus maybe another 4 hours of heavy drinking to wipe "better C" from your memory.

    Or pull your hair out.

  • q (unregistered) in reply to Otto
    Otto:

    Maurits:

    excerpt of cruise_missile_guidance_system.c...

    pos p = starting_position(), p_old, target = acquire_target();

    do {
        p_old = p;
        p = gps_query();
        trajectory t = vector(p_old, p);
        correction c = calculate_course(target, p, t);
        adjust_course(c);
    } forever;

    But your cruise missle doesn't need to run forever. You *obviously* need a check at the end to see if the missle has exploded, so you can exit the subroutine cleanly.

    [:D]



    Nah, it just crashes...
  • nowt (unregistered) in reply to chrismcb
    chrismcb:

    Arancaytar:
    > # define do_nothing
    Priceless.

     

    The concept isn't priceless, but the implementation surely is.

    I believe they are trying to achieve:

    if (a GT b) then

       do_nothing

    else

       blah blah blah

    endif //which I assume is in the snipped version

    Of course this won't compile because they didn't define do_nothing properly.




    No, that's precisley it.  do_nothing ensures that the program actually does nothing.  Genius!
  • (cs) in reply to The Bears
    Anonymous:

    The original Bourne shell takes this approach even further.

    Look at mac.h. Then look at args.c. Then go wash your brain out with vodka.



    This is funny; args.c nearly looks as if it was a shell script. Kind of recursive thinking.
  • (cs) in reply to Dan

    Dan:
    Skinnable programming languages - it's the future. Don't like your current language? Don't want to go to the hassle of writing your own language and compiler? Just pick a language that's close enough and skin it.

    <FONT face=Georgia>The horror, oh the horror!</FONT>

    <FONT face=Georgia>*Shudders*</FONT>

  • Your Name: (unregistered) in reply to foxyshadis

    foxyshadis:

    ...snip...

    Just because after having used so many other languages (every other language on the planet seems to have a "for each" construct) a codebase full of generic for loops is the ugliest thing on god's green earth besides my neighbor's lawn. And yes, I named them after the asm instructions for very-vague similarity.

    So far I've had more "hey, neat" than "wtf is this, are you insane", so I'd say success. =D

    #include <ALGORITHM>...

  • Your Name: (unregistered) in reply to foxyshadis

    foxyshadis:

    ...snip...

    Just because after having used so many other languages (every other language on the planet seems to have a "for each" construct) a codebase full of generic for loops is the ugliest thing on god's green earth besides my neighbor's lawn. And yes, I named them after the asm instructions for very-vague similarity.

    So far I've had more "hey, neat" than "wtf is this, are you insane", so I'd say success. =D

    std::for_each doesn't qualify?

  • (cs)

    The secret to Better Better C.

    #define #define //

  • LP (unregistered)

    I'm still waiting for Margarine C: "I can't believe it's not better!"

  • don (unregistered) in reply to LP

    This is right out of Paul Conte's book, "Common Sense C".

    http://ostg.pricegrabber.com/search_fullinfobk.php/isbn=1882419006

  • David Wolever (unregistered)

    Hey, look on the bright side!  At least he defined his macros properly (unless(p) if(NOT (p)) .  It would have been a REAL pain if he had used if (NOT p) and p happened to be something like 1 || 1...

  • Anon, I Moose (unregistered) in reply to Scott

    Is it so horrible to just do this?

    if (...) {
        ...
    } else {
        // do nothing
    }

    (where ... represents some number of statements/expressions)

    Writing code that deliberately doesn't do anything seems asinine to me and the opposite of clear.

  • (cs)

    So how many #defines would it take to achieve true natural language programming with C?

  • (cs) in reply to Arancaytar

    Arancaytar:
    > # define do_nothing
    Priceless.

    Listen, just because you people never got bitten by

    for (...);

    This post not [pi]-approved.

  • (cs) in reply to ajk

    Anonymous:
    Well Visual Studio has a standard header called iso646.h

    #include <ISO646.H>

    #pragma once
    #ifndef _ISO646
    #define _ISO646

    #if !defined(__cplusplus) || defined(_MSC_EXTENSIONS)
     #define and    &&
     #define and_eq    &=
     #define bitand    &
     #define bitor    |
     #define compl    ~
     #define not    !
     #define not_eq    !=
     #define or        ||
     #define or_eq    |=
     #define xor    ^
     #define xor_eq    ^=
    #endif /* !__cplusplus || _MSC_EXTENSIONS */

    #endif /* _ISO646 */
    <SNIP>

    This is an internationalization thing. A lot of keyboards don't have & on them, and there is a significant percentage out there lacking |, ~, ^ and !, as well. I would have thought they'd also define eq for consistency...

  • GmH (unregistered) in reply to R.Flowers
    R.Flowers:

    Yeah, the NE, EQ, etc. are Perly. Then we have MOD, which is VBish.

     

    At least in Perl there is a reason why they have both (gt,lt,eq,ne) and (>,<,==,!=) - the former are for lexical (string) comparison, the latter for numeric comparison; necessary because they use the one-type string-is-a-number-is-a-string approach (which could be considered a WTF in itself, but I digress...)

  • Chipset (unregistered)

    I think we all should compassionate the tortures you are up to :'(

  • TeamBob (unregistered) in reply to foxyshadis

    #define REP(x,y,z)              for((x)=(y);(x)<=(z);(x)++)
    #define REPN(x,y,z)             for((x)=(y);(x)<((z)-(y));(x)++)
    #define REPZ(x,z)               for((x)=0;(x)<=(z);(x)++)
    #define REPZN(x,z)              for((x)=0;(x)<(z);(x)++)

    I for one vote wtf is this are you insane...

    you forgot MOVB, MOVW

    here are some implementation suggestions:
    #define JNE(x, y) if (x) GOTO y;
    #define JZ(x,y) if (!x) GOTO y;

    Please note: I realise that it should be JNE/JE and JZ/JNZ. However most assemblers do not do it this way so we need to keep backward compatibility.

    Also please note: I HATE macros

  • Anonymous (unregistered) in reply to Fregas
    Anonymous:

    I especially  like these:

    #define forever   while(1)
    #define untilbreak forever
    #define untilreturn forever

    Nothing like adding your own inconsistencies.



    Hate me if you want, but these might be used to help constrain functions that need it, and add a little bit of commenting.

    If a specific function, perhaps a lookup, wants to be programmed in a specific way, then:

    while untilreturn
    {
        // Tells you that you should return, or that it breaks on a return.
    }

    Granted, this can also be done in commenting...

    while ( 1 ) // exit on return
    {
        // Tells you that you should return, or that it breaks on a return.
    }


    And also perhaps the do_nothing also adds some readability?  Not sure?
    That is, if you defined it by { and } (which still does nothing)
    #define do_nothing { }

    if ( x == y ) do_nothing
    else {
      printf( "X and Y are not equal!\n" );
    }

    Yes, yes... I guess the below tells it enough as it is.

    if ( x == y ) { }
    else {
        printf( "X and Y are not equal!\n" );
    }


    I have had the pleasure to work with people that could not understand the above { } and would have probably been better off with do_nothing.


    Furthermore, I have had instances in class projects where it is easier to dump in fortran syntax and port it with #defines than to actually go through line by line and convert the code.  These are instances where it is throw away code, or some internal testing or script code that is not very critical.

  • Thien (unregistered) in reply to PiV
    Anonymous:

    Don't be so melodramtic. I program in Python, Ruby, Java, C# and ObjC. Those are the languages I say I "know". However, I could sit down, right now, and fix a bug in a VB application if you gave me a couple of minutes to get comfortable.

    That being said, if someone who claims to know C sits down at this system, these syntax changes are nothing more than a nuisance. If you can't get beyond this, you don't deserve to be called a programmer.

    Sure, he didn't have to, but this is not a WTF...or at least not a major one.


    I think you actually answered why I consider this a WTF.  A person can sit down to program in a language even though he knows two other ones.  So why is it necessary to redefine the standard syntax of the language?

    I've always felt there are two types of WTF:
    Why the ... would you do that!?!
    vs
    What the ... !?!

    This would be of the 1st kind.
  • Kill yourself, Please. (unregistered) in reply to PiV
    Anonymous:
    Anonymous:
    Anonymous:

    Oh, it's just personal preference.  He didn't like the syntax, so he changed it.  Big deal.

     

     

    Well, it's obvious you don't maintain code in the real world, or else you'd understand why this sort of thing is one of the ultimate WTF's. Let's assume that the original code was around for 22 years, and ALL of the original programmers have moved on and/or died. And there's no documentation of the system. Now, one day, you inherit this code. And your boss asks to make some significant changes, and they need to be done yesterday. Not only do you have to learn all the programming idiosyncracies of all the programmers who came before you and modified this code, but you have to LEARN A NEW LANGUAGE!


    Don't be so melodramtic. I program in Python, Ruby, Java, C# and ObjC. Those are the languages I say I "know". However, I could sit down, right now, and fix a bug in a VB application if you gave me a couple of minutes to get comfortable.

    That being said, if someone who claims to know C sits down at this system, these syntax changes are nothing more than a nuisance. If you can't get beyond this, you don't deserve to be called a programmer.

    Sure, he didn't have to, but this is not a WTF...or at least not a major one.


    I am going to guess that you are a student or a hobbiest. 

    The statement about being able to sit down in an unknown language (and I assume unknown application) and fix a bug in a "couple of minutes" is a telling sign.  I believe the average for the program I am currently working on is somewhere around 20 hours to fix a bug.  The fastest is probably 20-30 minutes and the longest is close to 3 months (and at least 5 different developers).

    As a maintainer, I have seen plently of jackasses do stupid things like this.  If you are too stupid/lazy to learn the language you are using, kill yourself, please.

    There is no excuse for shit like this and it should be allowed as a defense for murder.


  • Rainer Zufall (unregistered)

    <FONT face="Courier New">#define 0 1</FONT>

    <FONT face="Courier New">#define 1 i</FONT>

    <FONT face="Courier New">#define i j</FONT>

  • burp (unregistered) in reply to Dan
    Anonymous:
    Skinnable programming languages - it's the future.

    Don't like your current language? Don't want to go to the hassle of writing your own language and compiler? Just pick a language that's close enough and skin it.

    Sounds like .Net

  • Being a bit bored.. (unregistered) in reply to Arancaytar
    Arancaytar:
    > # define do_nothing
    Priceless.

    Well, Edgar Dijkstra, defined a "skip" opetator..

    I've done something of the kind when I was bitten by a confusion between = and ==

    and things like

    #define If if ( #define Then ) { #define Else } else { #define Elsif } else if ( #define End }

    ...

    Pascalesque, I know..

  • stephen (unregistered) in reply to ZeoS
    ZeoS:
    The real WTF is that there are people still programing in C

    Yeah, OSX kernal should be rewritten in VB.net.

    Seriously I don't see the WTF.  You read some C code, see a strange header file, take a look and see that it is just a bunch of defines to change the syntax.  No prob, you write a short perl script that changes everything back to normal (does exactly what the c preprocessor does) and charge at least a days work for it.

    This guy did a favour for those that followed.
  • (cs) in reply to boogieman
    Anonymous:
    Reminds me of my software engineering professor.  He was convinced that C was the worst thing ever conceived.

    And yet he said the language would be a hundred times better if we added the following lines to the top of our code:
    #define BEGIN {
    #define END }

    I've seen that in C code used in multinational corporations more than once, C code created by people with university degrees in computer science and software engineering...

  • Ritesh (unregistered) in reply to The Bears
    Anonymous:

    The original Bourne shell takes this approach even further.

    Look at mac.h. Then look at args.c. Then go wash your brain out with vodka.

    This is the most surprising fact. A developer like Stephen Bourne is using something like that. [8-)]

     

  • John Hensley (unregistered)

    Defining your own boolean type in C (or worse, post-standard C++) isn't much different from this.

  • Ben Cooke (unregistered)

    I must confess that I've #defined an "unless" construct for myself before too. It's such a handy construct in perl; it's amazing how much more readable code can be when you have a negative conditional construct rather than having to write "if (! ...)" all the time. It's a shame that it isn't available in more languages.

  • Ad Hominous Cow Herd (unregistered) in reply to boogieman
    Anonymous:
    Reminds me of my software engineering professor.  He was convinced that C was the worst thing ever conceived.

    It is, but it has nothing to with syntax.

  • Peter Makholm (unregistered) in reply to Rank Amateur

    My first thought would be more along the lines of 'Ohhh no, not again' than WTF.

    Rank Amateur:

    #define ASSIGN(x,y) (x) = (y)
    #define ADD(x,y) (x) + (y)
    #define SUBTRACT(x,y) (x) - (y)


    The real WTF will come when he do something like this:

    #define SQR(x) (x)*(x)

    and tries to print a range of quadratic numbers:

    i = 1;
    repeat {
    printf("%03d", SQR(i++));
    } until (i GT 10);

    and then tries to fix the problem.



  • Keith (unregistered) in reply to akrotkov
    akrotkov:
    Anonymous:
    I never did like those pesky equal signs anyway.

    #define CURLY_OPEN_BRACE {




    ??(
    ??[

    Anyone remember these?


    Oh my God!

    I actually remember using these on a teletype back in the early eighties. Did nothing for program readability.

Leave a comment on “The Secret to Better C”

Log In or post as a guest

Replying to comment #:

« Return to Article