Post funny code/snippets you came across

The DailyWTF has them all.

One of my favourites:
thedailywtf.com

Dave.cpp

Noah Finkelstein's coworker Dave was a strange fellow. When he wasn't mumbling to himself in his cubicle, he could be found in deep thought at the snack machine, pondering whether to get animal crackers or Lorna Doones. He'd always get the Lorna Doones, but swear that next time, he'd go for the...
thedailywtf.com
 
One of my favorites:

Code: 
if (root->next->next)
    free(root->next->next);
if (root->next)
    free(root->next);
if (root)
    free(root);
Only it was many levels bejond these 2.

And
Code: 
 if (0 < request->len < dev>maxlen)
     do_io(dev, request);
 
Not void pointers, these make sense. I am talking about abominations like
C: 
int foo(void);

Why? Because if you don't need parameters, then just pass nothing at all.
 
But if one is actually paying attention to compiler warnings or have "warnings == errors" declarations using void catch callers doing the wrong thing and putting a parameter on the call.

what if
int foo(double) but someone calls it as
uint64_t x=12345L;
foo(x);

If you ignore compiler warnings, you are going to get unexpected results.

So my opinion, current C/C++ declaring int foo(void) is the correct thing to do, especially if you also compile with "warnings == errors". You catch callers doing the wrong thing. It's never about the creators of the function (library) it's about the callers of that function.
 
Code: 
 void (*p)(const char  *, ...) __printflike(1, 2) =
            (mp->mnt_flag & MNT_RDONLY) == 0 ? panic : printf;
 
 
 (*p)("%s: bad dir ino %ju at offset %d: %s\n",
            mp->mnt_stat.f_mntonname, (uintmax_t)ip->i_number,
            offset, how);

--netbsd
 
You are absolutely right mer, that's the reason why foo(void) is good. I'm not sure about your example but this:
Code: 
void foo() { return 42; } 
...
foo(0x42)
Is OK. If it was defined as void foo(void) { return 42; } it would be an error.
 
_martin that's the thing a lot of folks forget:
The interface defines "how I should be called".
C++ and overloading, it becomes very important on how things are defined.
Older versions of C standards, were pretty loose on how things could be called; automatic type promotion/demotion, pushing things onto the call stack that don't get use.

So, my opinion, ret-type foo(void) is a good thing.
Make the compiler do the work, set warnings == error and pay attention to the compiler output.
 
eternal_noob said:
Not void pointers, these make sense. I am talking about abominations like
C: 
int foo(void);

Why? Because if you don't need parameters, then just pass nothing at all.
Click to expand...
That is in the standard. Foo(void); means no parameters, but foo() actually means (....); That is the elipsis which means "anything goes". How the function will access these can be by magic or inline assembly. But there we get dirty fast.
 
eternal_noob Yep that should be the defaults in my opinion. It's ironic how many "weird little bugs" are actually fixed if you pay attention and correct compiler warnings.
Been a while since I looked but I think C++ treats int foo() like int foo(...) as Crivens points out. That may be relaxed or tightened in some versions of C++, I just don't recall any more.
 
But as Crivens points out there was a time before C++11. One has to work with the tools one has and most times compilers and toolsets in use lag behind standards.
For a single user updating/upgrading toolsets is relatively painless; across an organization of more than 10 developers, it becomes painful.
 
One may think that, but it's not always the case, especially if one has to maintain a large codebase written before C++11
 
eternal_noob said:
C++11 was approved in 2011. It's 2023. That's an eternity in IT.

I think one can safely use C++11 nowadays ;)
Click to expand...
Simply, no.
I wish it would, but no. For new things, maybe. For things with a long development time, this won't fly. I feel a rant comming up.
I work in infrastructure development right now, one of the big things is that the code bases are sometimes OLD. And you can't compile that with a new compiler. Changing that would mean you need to re-verify the complete product, all the way to the things you delivered DECADES ago because updates are not limited to half a year here. And that is only a small company.

I was a big fan of C++ for a long time. But this development by comitee drove me away. They throw anything in there, plus kitchen sink and roomba, whatever they deem good. What is good about a language is clearity in expression. That is missing for a long time now, because who can read all these new addons and know what they mean? That is not clear in expression, it requires an immense trove of details about the runtime, the frameworks, the context to know what is written on a page of dense C++11 that uses all the tricks.
 
Alain De Vos If I read that code of yours correctly, you can add fields to a class definition from a method? The children part? Or is that a bug?
 
You must log in or register to reply here.
Back
Top