• Jay (unregistered) in reply to frits
    frits:
    This not only compiles, but signal my intent to cast "I Like Puppies!" to a long. I'm not sure where this could ever be useful.

    That would be useful if you only like long puppies, like daschunds.

  • Jay (unregistered) in reply to Zecc
    Zecc:
    Drew:
    Write code that has better type safety, then casting becomes less of a concern. :P
    Write in a language with no type safety at all, and casting will become a distant memory!

    That's the only way I can think of to give people FOND memories of casting.

  • Patrick (unregistered) in reply to SR
    SR:
    Patrick:
    Yes, but this isn't C. It's C-Pound
    I prefer C-Hash
    So do I, unfortunately that's not what the title of the article was.
  • Jay (unregistered) in reply to Lawrence
    Lawrence:
    Indeed! Switch to perl and never cast again.
    <remark type='lame'> Unless you have to cast your Perl before swine. </remark>
  • iMalc (unregistered)

    If by chance the function actually made the page smaller without screwing up the page contents, then surely he's helped out those people downloading it over a 300 baud modem! I mean that bit of code could easily save several seconds per page, even after acounting for how long the function takes to run...

  • Plz Send Me The Code (unregistered) in reply to Mason Wheeler
    Mason Wheeler:
    ObiWayneKenobi:
    What is with all these so-called "Senior Developers" and crap code (and usually a crappier atittude)? Nearly every "Senior Developer" I've worked with hasn't been senior at anything and seems to be senior in terms of tenure and not skill.

    Maybe I'm just lucky, but where I work, our Project Architect (the senior developer on the project I'm on) is exactly what a senior dev should be. He's literally been with the company longer than anyone but the CEO, he seems to know what anything in the program does and where the code responsible for it is, and he's friendly and easy to talk to.

    Oh, and he writes pretty good code too.

    Same with our Project Architect. Oh wait, I AM the project architect. What a swell guy!

  • XioPod (unregistered)

    This won't compile in C#...

        private T cast<T>(T i)
        {
            return (T)i;
        }
        private void test()
        {
            long i = cast<long>("I Like Puppies!");
        }
    

    Error The best overloaded method match for 'cast<long>(long)' has some invalid arguments

  • Doug (unregistered) in reply to frits
    frits:
    In C++ templates, the compiler generates the code at compile time, so you still get compiler type checking and code optimization. C# generics do none of this. Note my example:
    long i = Cast<long>("I Like Puppies!");
    
    
    

    This not only compiles, but signal my intent to cast "I Like Puppies!" to a long. I'm not sure where this could ever be useful.

    So, it's the same thing as

    long i = (long)("I Like Puppies!");
    

    just like in C, C++, and Java. I agree -- a worthless construct. If the compiler can manage to inline and optimize everything (which it should be able to do, in theory), then all's good in performance land. The only WTF, then, is the questionable syntax advantage.

  • Dirge (unregistered)

    So for everyone slamming the regex - which takes longer to process: the regex that removes whitespace, or the gzip compression that the webserver will do on the whitespace if the webserver is configured properly? That's an honest question. I'd think it would be best to do whitespace-removal (and other size optimizations, a la Google's toolkit) as a one-time operation (a "build" of the developer-friendly HTML/Javascript/etc. into the bandwidth-friendly pre-compressed version) instead of every time a page loads, but it's going to happen somewhere along the way unless the webserver has been deliberately configured not to gzip HTML content, which is usually a huge performance hit for users.

  • (cs) in reply to XioPod
    XioPod:
    This won't compile in C#...
        private T cast<T>(T i)
        {
            return (T)i;
        }
        private void test()
        {
            long i = cast<long>("I Like Puppies!");
        }
    

    Error The best overloaded method match for 'cast<long>(long)' has some invalid arguments

    No. But this will:

            public T Cast<T>(object obj) { return (T)obj; }
    
            private void test()
            {
                long i = cast<long>("I Like Puppies!");
            }
    
    
    
    

    What's wrong? CTRL+C, CTRL+V broken ?

  • (cs) in reply to Doug
    Doug:
    frits:
    In C++ templates, the compiler generates the code at compile time, so you still get compiler type checking and code optimization. C# generics do none of this. Note my example:
    long i = Cast<long>("I Like Puppies!");
    
    
    

    This not only compiles, but signal my intent to cast "I Like Puppies!" to a long. I'm not sure where this could ever be useful.

    So, it's the same thing as

    long i = (long)("I Like Puppies!");
    

    just like in C, C++, and Java. I agree -- a worthless construct. If the compiler can manage to inline and optimize everything (which it should be able to do, in theory), then all's good in performance land. The only WTF, then, is the questionable syntax advantage.

    Uh... No. Do you actually write code? That won't compile, the code in the article will.

  • tom (unregistered)

    wouldn't the server send the html twice, as the writer isnt cleared?

  • Steve (unregistered)
    But be didn't; he knew he was right

    Who?

  • Doug (unregistered) in reply to frits
    frits:
    Uh... No. Do you actually write code? That won't compile, the code in the article will.

    My code is valid C and C++. Maybe not C#, and Java might have problems with it (I'll check that next). I even ran it through gcc just to make sure.

    But even if it weren't valid, it still makes the point about the intent of the code.

  • Steve (unregistered) in reply to Doug
    Doug:
    frits:
    Uh... No. Do you actually write code? That won't compile, the code in the article will.

    My code is valid C and C++. Maybe not C#, and Java might have problems with it (I'll check that next). I even ran it through gcc just to make sure.

    But even if it weren't valid, it still makes the point about the intent of the code.

    Yep, that's perfectly legal to do. Gotta love people that just assume they know more than you, huh? Do you actually write code, frits?

  • Doug (unregistered) in reply to Doug
    Doug:
    frits:
    Uh... No. Do you actually write code? That won't compile, the code in the article will.

    My code is valid C and C++. Maybe not C#, and Java might have problems with it (I'll check that next). I even ran it through gcc just to make sure.

    But even if it weren't valid, it still makes the point about the intent of the code.

    Confirmed: java barfs hard. I suspect C# does as well. So, that explains our differences, doesn't it? Please double check before posting in the future, to avoid such confusion.

  • (cs) in reply to Steve
    Steve:
    Do you actually write code, frits?

    Yep.

  • Anonymous (unregistered) in reply to Doug

    Doesn't work in Java, does work in C/C++.

  • Doug (unregistered) in reply to Steve
    Steve:
    Yep, that's perfectly legal to do. Gotta love people that just assume they know more than you, huh? Do you actually write code, frits?

    Oh, give some benefit of the doubt -- frits probably just missed that I was talking about C/C++, rather than the C# from the original example.

  • (cs) in reply to Doug
    Doug:
    Steve:
    Yep, that's perfectly legal to do. Gotta love people that just assume they know more than you, huh? Do you actually write code, frits?

    Oh, give some benefit of the doubt -- frits probably just missed that I was talking about C/C++, rather than the C# from the original example.

    Since you mentioned four languages in one post, is it any wonder I couldn't follow? Not to mention you were dead wrong about the only language used in the article.

  • Steve (unregistered) in reply to Doug
    Doug:
    Steve:
    Yep, that's perfectly legal to do. Gotta love people that just assume they know more than you, huh? Do you actually write code, frits?

    Oh, give some benefit of the doubt -- frits probably just missed that I was talking about C/C++, rather than the C# from the original example.

    He still didn't need the "do you actually write code" comment. It's one thing to be condescending, it's another to be condescending when you don't know what you're talking about.

    It reminds me of management.

  • Anonymous (unregistered) in reply to frits
    frits:
    Since you mentioned four languages in one post, is it any wonder I couldn't follow? Not to mention you were dead wrong about the only language used in the article.

    Yes. Four is a pretty big number, but I think you miscounted.

    just like in C, C++, and Java.

    The only one he was wrong about is Java, no mention of C#.

  • Your Name (unregistered) in reply to Dirge
    Dirge:
    which takes longer to process: the regex that removes whitespace, or the gzip compression that the webserver will do on the whitespace if the webserver is configured properly?
    Not directly at you, sir, but along the same lines --

    There has to be a category of bad code just for the Gedanken Optimizer. "I just KNOW it will run faster!"

    Clients and I, we live in real world; please do performance testing sir...

  • AA (unregistered)

    TRWTF is that Alex doesn't realize <int> needs to have the angle-brackets escaped if it appears in regular HTML.

  • Doug (unregistered) in reply to frits
    frits:
    Since you mentioned four languages in one post, is it any wonder I couldn't follow? Not to mention you were dead wrong about the only language used in the article.

    Oh, come on. Let's be mature about this. From the very start I have said that I don't know C#. I have never written one line of code in C#, and probably won't in the foreseeable future.

    I also clearly marked that line as being an equivalent C/C++/Java construct (although I admit I was wrong about Java) -- there should have been no confusion.

    Lastly, four items is not that hard to keep track of. I use up to SEVEN different programming languages every day: C, C++, Java, Perl, Bash, Csh, and an in-house language. I probably even missed one or two. Don't come to me whining about a measly four languages, especially when I was as clean as I was.

    Anonymous:
    The only one he was wrong about is Java, no mention of C#.

    To be fair, the parts of the paragraph about optimization can be interpreted as referring to C#, even if not explicitly mentioned by name.

  • (cs) in reply to Anonymous
    Anonymous:
    frits:
    Since you mentioned three languages in reference to a comment about a fourth language, is it any wonder I couldn't follow? Not to mention you were dead wrong about the only language used in the article.

    Yes. Four is a pretty big number, but I think you miscounted.

    just like in C, C++, and Java.

    The only one he was wrong about is Java, no mention of C#.

    FTFM

  • Bim Job (unregistered) in reply to frits
    frits:
    Steve:
    Do you actually write code, frits?

    Yep.

    Always nice to know that people ask relevant questions.

    Dumb questions. But relevant.

  • Eric Cartman (unregistered) in reply to Debuggery
    Debuggery:
    Crazy pointer manipulation is bad! Stop doing it.
    [image] *SCNR* watched southpark a few minutes ago... ;)
  • Buffled (unregistered) in reply to Chris McKenzie
    Chris McKenzie:
    The Cast<T> function works well as an extension method for a Fluent API. I used something similar in a hand-rolled Dependency Injection framework. I wrote my implementation as "return value as T;" instead. In this way, the responsibility of testing for null is on the caller, and the exception is only thrown if they fail to do it.
    Thank you for posting your real name. Now I will know it if it ever comes across my desk on a resume, and can reject it out of hand.
  • ClutchDude (unregistered) in reply to Dirge
    Dirge:
    So for everyone slamming the regex - which takes longer to process: the regex that removes whitespace, or the gzip compression that the webserver will do on the whitespace if the webserver is configured properly? That's an honest question. I'd think it would be best to do whitespace-removal (and other size optimizations, a la Google's toolkit) as a one-time operation (a "build" of the developer-friendly HTML/Javascript/etc. into the bandwidth-friendly pre-compressed version) instead of every time a page loads, but it's going to happen somewhere along the way unless the webserver has been deliberately configured not to gzip HTML content, which is usually a huge performance hit for users.
    Interesting.

    The compression is pretty small in terms of the cpu time you take vs. the bandwidth savings you get and the fact it'll still get to the person faster.

    In regards to minifying the HTML/JS/CSS, the algorithms used to minify them are actually a bit intense as it does a bit more than just a quick run through to remove spacing. It looks at variable names, methods and more.

    Between a good caching setup for images, css and javascript and enabling gzip, you're cutting the actual total response size alot. I'd be surprised if minifying html on the fly would result in much more savings vs. cpu time.

    Speaking of gzip, why isn't thedailywtf.com using it?

  • @Deprecated (unregistered) in reply to Doug
    Doug:
    ... Please double check before posting in the future, to avoid such confusion.

    What!? This wouldn't be The Daily WTF then, would it!

    BTW, that caching example is the best "maybe I needing later" I have ever seen!

  • StychoKiller (unregistered) in reply to SR
    SR:
    Patrick:
    Yes, but this isn't C. It's [url=http://thedailywtf.com/Articles/5_years_C-pound_experience.aspx]C-Pound[/url

    I prefer C-Hash

    It's actually C-Octothorpe!

  • jeff (unregistered) in reply to Patrick
    Patrick:

    captcha: damnum - using the wrong magic number, and the whole system falls apart.

    Wouldn't that be Götterdämmernum?

    captcha: secundum - doing the above twice?

  • poop (unregistered)

    So you're complaining because he's using a monad for rendering? Not the best architectural choice given the platform, but... so what? This is transparent code.

  • Tannen (unregistered) in reply to Debuggery

    I've always pronounced # as the "rap" sign, as in "C#".

  • Quirkafleeg (unregistered) in reply to frits
    frits:
    In C++ templates, the compiler generates the code at compile time, so you still get compiler type checking and code optimization. C# generics do none of this. Note my example:
    long i = Cast<long>("I Like Puppies!");
    This not only compiles, but signal my intent to cast "I Like Puppies!" to a long. I'm not sure where this could ever be useful.
    Or even safe, given that long int isn't necessarily large enough for a pointer; which is why intptr_t exists.
  • (cs) in reply to nobody
    nobody:
    I wish somebody would proofread the articles before posting :/
    ^ This.
  • SomeCoder (unregistered) in reply to Bim Job
    Bim Job:

    In these circumstances, I like to ask myself whether I know better than the designer(s) of the language. To five nines accuracy, my answer is that I do not.

    Why would I be providing syntactic sugar when the language designer has decided that it is either unnecessary or a very bad thing?

    While I would generally agree with you, if you've ever had to dig down into the guts of C# and/or read any interview with the designer of C#, you'd know this statement isn't entirely accurate The designer of C# basically only made the language because of some sort of vendetta against C/C++. I guess C++ must have murdered his family or something :)

    At least that's the impression I get when reading people's interviews with him :)

    I'm only joking... sort of...

    That said, I'm not defending today's WTF, just strongly implying that the designer of C# is crazy :)

  • Coward (unregistered) in reply to Ed

    You clearly don't have a good understanding of C++ style casts then. They can do everything a C style cast can, and only require that you understand the appropriate cast for the job. As not to accidentally change the nature of the data you are manipulating.

  • C# Man (unregistered) in reply to StychoKiller
    StychoKiller:
    SR:
    Patrick:
    Yes, but this isn't C. It's [url=http://thedailywtf.com/Articles/5_years_C-pound_experience.aspx]C-Pound[/url

    I prefer C-Hash

    It's actually C-Octothorpe!

    I don't know why you Americans pronounce it Pound. This is a pound sign £, and this is a hash sign # otherwise own as sharp (as in musical notation). At least anytime I phone an automated phone line I'm always asked to push the 'hash' sign after keying in some number.

  • Escaped Lunatic (unregistered) in reply to Coward
    Coward:
    You clearly don't have a good understanding of C++ style casts then. They can do everything a C style cast can, and only require that you understand the appropriate cast for the job. As not to accidentally change the nature of the data you are manipulating.

    Wrong. Sort of.

    You cannot reinterpret_cast<float>(int). You need to do the ugly-fugly ((float)(&int)) instead. Well, I suppose you could do reinterpret_cast<float>(&int) , but that is just as ugly.

    Ah, the joys of floating point formats not supported by the processor or the compiler...

  • Quirkafleeg (unregistered) in reply to C# Man
    C# Man:
    I don't know why you Americans pronounce it Pound. This is a pound sign £, and this is a hash sign # otherwise own as sharp (as in musical notation).
    Almost. This ‘♯’ is ‘sharp’, so on that point your comment quite ♮ly falls ♭.
  • Templator (unregistered) in reply to frits
    frits:
    Doug:
    frits:
    TheCPUWizard:
    While the second two are WTF's, the first one is NOT.

    The "T y = (T) x;" for suffers greatly from discoverability. The implementation of a "T Cast<T>(...)" makes casting much more discoverable.

    This is (partially) the reason why C++ implemented dynamc_cast<T>, static_cast<T>, reinterpret_cast<T>, const_cast<T>.

    I hope you're being sarcastic.

    That function may be much more discoverable, but it creates penalties from boxing/unboxing (if using value types) and an unneccessary function call. It also negates compiler checks for casts. The following code will compile using function in the article:

    long i = Cast<long>("I Like Puppies!");
    
    
    

    BTW- Who needs to search for all instances of casts anyway?

    No, he's not being sarcastic.

    I'm not an expert on C-NumberSign, but those casts were designed for C++ (which I do know a thing or two about). Here it is straight from the horse's mouth:

    http://www2.research.att.com/~bs/bs_faq2.html#static-cast

    To summarize, the primary reason for the new syntax is to make casting intent more clear. The secondary reason is to make casts stand out more visually: "An ugly operation should have an ugly syntactic form." Lastly, Stroustrup suggests that programmers will simply avoid casts because of this syntax. (Unfortunately, most programmers seem to fall back to the C-style cast syntax, from my experience.)

    So, maybe TRWTF is that C# didn't import the C++ casting syntax ... and this programmer decided to put it back in? (again, I'm no expert on C#, so please correct me if I'm off base here).

    In C++ templates, the compiler generates the code at compile time, so you still get compiler type checking and code optimization. C# generics do none of this. Note my example:

    long i = Cast<long>("I Like Puppies!");
    
    
    

    This not only compiles, but signal my intent to cast "I Like Puppies!" to a long. I'm not sure where this could ever be useful.

    In C++ (type)var is known as a C-Style cast and anyone who's read More Effective C++ knows that static_cast<> is the preferred method in C++. More obvious it's a cast and looks more like the other C++ style casts (const_cast<>, reinterpret_cast<> etc...)

    I'm not sure how it works in C# - I've not used it much (in fact I didn't even know it supported templates...)

  • RogerWilco (unregistered) in reply to Escaped Lunatic
    Escaped Lunatic:
    Coward:
    You clearly don't have a good understanding of C++ style casts then. They can do everything a C style cast can, and only require that you understand the appropriate cast for the job. As not to accidentally change the nature of the data you are manipulating.

    Wrong. Sort of.

    You cannot reinterpret_cast<float>(int). You need to do the ugly-fugly ((float)(&int)) instead. Well, I suppose you could do reinterpret_cast<float>(&int) , but that is just as ugly.

    Ah, the joys of floating point formats not supported by the processor or the compiler...

    Well, if I understand the reasoning behind C++ casting correctly, it is to make things look ugly so the programmer doesn't use them lightly. So if you find it ugly, I'm thinking "mission accomplished".

    Captcha: tego, like lego, but concealed.

  • dividius (unregistered) in reply to Anonymous
    Anonymous:
    Debuggery:
    I was about to say the same thing. Anyone who thinks the first one is a serious WTF has never had to search for a bloody C style cast.
    Hardly surprising, considering this isn't even C.

    No, but it sure as heck offers "C style" casts. RTFC.

    Captcha: jumentum - you're on a roll!

  • (cs) in reply to Jay
    Jay:
    frits:
    This not only compiles, but signal my intent to cast "I Like Puppies!" to a long. I'm not sure where this could ever be useful.

    That would be useful if you only like long puppies, like daschunds.

    I LOVE dachshund puppies.

    [image]
  • Grieg (unregistered) in reply to Quirkafleeg
    Quirkafleeg:
    C# Man:
    I don't know why you Americans pronounce it Pound. This is a pound sign £, and this is a hash sign # otherwise own as sharp (as in musical notation).
    Almost. This ‘♯’ is ‘sharp’, so on that point your comment quite ♮ly falls ♭.

    I was about to make the same point!! (and quite appropriately, the captcha is 'secundum')

  • (cs) in reply to TheCPUWizard
    TheCPUWizard:
    While the second two are WTF's, the first one is NOT.

    The "T y = (T) x;" for suffers greatly from discoverability. The implementation of a "T Cast<T>(...)" makes casting much more discoverable.

    Much less stupid workaround:

    #define CAST int x = (CAST int)2.1;

    define CAST as nothing, and you're free to stick it next to any casts without having any effect at all on the compiled code, while making said casts easy to locate.

    Or if not using C, of course, use the methods provided by your language.

  • dag (unregistered) in reply to V
    V:
    Reminds me of a senior developer I knew. He got to a point where he was completely unwilling to learn any new programming techniques, did everything as though he had no memory and the code would never be maintained. ...

    Must be the atmosphere here, but when you wrote 'no memory' I assumed for a second that you're talking about embedded systems... ;-)

  • (cs) in reply to frits
    frits:
    long i = Cast<long>("I Like Puppies!");
    

    This not only compiles, but signal my intent to cast "I Like Puppies!" to a long. I'm not sure where this could ever be useful.

    Obviously, in case you want to redefine Cast so that it supports interpreting a string as a base-whatever number using a digit set of alphanumeric characters and assorted punctuation marks. Though in that case "I Like Puppies!" might not fit into a long, so make sure you check for overflow.

Leave a comment on “Rendered Pointless”

Log In or post as a guest

Replying to comment #:

« Return to Article