• Adam (unregistered)

    Wow.

  • (cs)

    There is nothing shinier than long, complicated regular expressions without any comments.

  • AndrewB (unregistered)

    I think I'm supposed to sit here in my pajamas and think about what this code is doing before I can find it funny. I just can't...

  • TheCPUWizard (unregistered)

    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>.

  • Ed (unregistered) 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.

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

    The seperate cast methods in C++ may be the most horrifically difficult to use things I've ever encountered, especially in code that thrives on crazy pointer manipulation and Templates.

  • Debuggery (unregistered) in reply to TheCPUWizard

    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.

  • hmemcpy (unregistered) 
    Cast<T>(this object obj, T type)
    is great if you want to return anonymous object from a method! 
    private object GetData()
{
  return new { Name = "James", LastName = "Dean" };
}

var data = GetData().Cast(new { Name = "", LastName = "" });

// use data.Name and data.LastName now...
  • Debuggery (unregistered) in reply to Ed
    Ed:
    The seperate cast methods in C++ may be the most horrifically difficult to use things I've ever encountered, especially in code that thrives on crazy pointer manipulation and Templates.

    Of course they're difficult to use in crazy pointer manipulation: crazy pointer manipulation is bad. Stop doing it. Declarative casts are designed to keep type manipulation sane and compile time checked.

    There are only four separate casts, and two of them are only for extreme situations. The other two are extremely simple.

  • Ed (unregistered) in reply to Debuggery
    Debuggery:
    Ed:
    The seperate cast methods in C++ may be the most horrifically difficult to use things I've ever encountered, especially in code that thrives on crazy pointer manipulation and Templates.

    Of course they're difficult to use in crazy pointer manipulation: crazy pointer manipulation is bad. Stop doing it. Declarative casts are designed to keep type manipulation sane and compile time checked.

    There are only four separate casts, and two of them are only for extreme situations. The other two are extremely simple.

    That depends on the functionality you are trying to achieve: you try writing a monte-carlo neural network simulation framework without doing some very crazy pointer based nonsense. Every methodology and technique has its place (except Waterfall, that's just b*llocks).

  • V (unregistered)

    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. But he was amazing, I saw him accomplish some huge feats but in the must screwed up ways.

  • Patrick (unregistered)

    looks like those regexes are supposed to strip superfluous whitespace, but there's a syntax error at position 6 on the first one, and the second one is useless garbage.

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

  • Patrick (unregistered) in reply to Debuggery
    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.
    Yes, but this isn't C. It's C-Pound

    This is not spam, Akismet!

  • Anonymous (unregistered)

    Throwing in a bunch of unneccessary regexes is a sure fire way to speed up execution. After all, it's not like the regex classes are slow, is it? It's not like they have the highest cyclomatic complexity of any classes in the entire .NET framework, is it? What's that? They do? Oh, crap.

  • Mako (unregistered)

    You idiots. In the caching example, he is doing the right thing.

    When an app gets heavily used it is often SLOWER to get from the cache than to compute the data on the spot. This man obviously has the experience that all of you lack to foresee this.

    The cache insert is there for REDUNDANCY, because this senior developer knows very damn well that one of the junior devs will screw up the system, and that's why you need to make sure you have backups.

    Truly this man is top notch.

  • Anonymous (unregistered) in reply to Debuggery
    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.
  • (cs)
    Cast<T>(this object obj, T type)

    is great if you want to return anonymous object from a method!

    this will crash if your object is null, and this new notation is a big fat and ugly bull######it.

    If you think the cast function is useful, you're the kind of person who create these functions :

    int Multiply(int i,int y) int Add (int i, int y) int Substract(int i,int y)

    Why do these stupid programmers create operator when we can create dozens of useless functions ?

  • Debuggery (unregistered) in reply to Patrick
    Patrick:
    Yes, but this isn't C.

    C-Pound (lol) has the same style of static casts as C. It's pretty likely they chose this style because it was mimicking C. Dynamic ones can be done with different syntax, thankfully.

    As the issue with C style casts is how good they are at hiding, all the languages that do them in the same style have the same issue, whether it's C-Hash, Java, etc...

  • Drew (unregistered)

    Write code that has better type safety, then casting becomes less of a concern. :P

  • Anonymous (unregistered) in reply to remibourgarel
    remibourgarel:
    Cast<T>(this object obj, T type)

    is great if you want to return anonymous object from a method!

    this will crash if your object is null, and this new notation is a big fat and ugly bull######it.

    If you think the cast function is useful, you're the kind of person who create these functions :

    int Multiply(int i,int y) int Add (int i, int y) int Substract(int i,int y)

    public object CastToObject(object o)
{
  return (o as object);
}
  • (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.

    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?

  • (cs) in reply to Drew
    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!
  • TheCPUWizard (unregistered) in reply to frits
    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?

    1. Note that I only shoed the signature. Boxing/Unboxing can be totally avoided, impossible casts detected, and nop-op casts optimized away within the implementation.

    2)Being able to quickly and reliably locate casts is very often an important task, especially when considering re-factoring. In many high-reliability/high-perormance applications documenting all of the casts [except for implicit casts to a base/interface] is regularly required.

  • (cs) in reply to hmemcpy
    hmemcpy:
    Cast<T>(this object obj, T type)
    is great if you want to return anonymous object from a method! 
    private object GetData()
{
  return new { Name = "James", LastName = "Dean" };
}

var data = GetData().Cast(new { Name = "", LastName = "" });

// use data.Name and data.LastName now...

    Cast-by-example is one of the most wretchedly evil hacks ever discovered. Any code I see using this is going straight to the trash heap.

  • MadX (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!

    I miss dBase...

  • sirlewk (unregistered)

    Not a WTF. Doing caching like this makes sense on embedded systems where you don't have a filesystem to retreive previously cached data from.

  • (cs) in reply to TheCPUWizard
    TheCPUWizard:
    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?

    1. Note that I only shoed the signature.
    I don't care what you showed. The whole function- the one you say is not a WTF- is shown in the article.

    Boxing/Unboxing can be totally avoided, Not true. Unless you constrain the input to reference types only. impossible casts detected, By what, throwing an exception at runtime? and nop-op casts optimized away within the implementation. Please give an example of this wizardry.

    2)Being able to quickly and reliably locate casts is very often an important task, especially when considering re-factoring. In many high-reliability/high-perormance applications documenting all of the casts [except for implicit casts to a base/interface] is regularly required. If you say so. Your argument would hold more water with some examples. I personally have never seen this requirement.

  • Patrick (unregistered) in reply to Debuggery
    Debuggery:
    Patrick:
    Yes, but this isn't C.

    C-Pound (lol) has the same style of static casts as C. It's pretty likely they chose this style because it was mimicking C. Dynamic ones can be done with different syntax, thankfully.

    As the issue with C style casts is how good they are at hiding, all the languages that do them in the same style have the same issue, whether it's C-Hash, Java, etc...

    Personally, I like Delphi's cast over C-style: typename(objectname) And there aren't many things I like about Delphi.

    Better still would be to put the cast after the variable name so you can continue down a long chain without all the brackets: datasource<DataTable>.rows[0][0]<string>.StartsWith("a")<int>;

  • (cs)

    Casts are evil!

    http://www.parashift.com/c++-faq-lite/coding-standards.html#faq-27.11

  • Anon (unregistered) in reply to Cbuttius
    Cbuttius:
    Casts are evil!

    http://www.parashift.com/c++-faq-lite/coding-standards.html#faq-27.11

    Of course they are.

    http://yosefk.com/c++fqa/picture.html#fqa-6.15

  • SR (unregistered) in reply to MadX
    MadX:
    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!

    I miss dBase...

    I live for the days when bug reports from our ColdFusion legacy apps land on my desk.

    Sarcasm? You decide :o)

  • SR (unregistered) in reply to Patrick
    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

  • SR (unregistered) in reply to SR
    SR:
    Patrick:
    Yes, but this isn't C. It's C-Pound

    I prefer C-Hash

    D'oh! Sorry I wrecked your URL tag.

    CAPTCHA: ullamcorper. In common with everyone who lists their CAPTCHA I can't think of anything funny, I just think it's a magnificent word

  • Bim Job (unregistered)

    Casting to one side (er) ...

    The first two examples are very nearly perfect implementations of the venerable HP engineering adage, "Keep It Simple, Stupid!"

    The third example is, unfortunately, an anti-KISS.

    The problem with the first two examples is that the Senior Developer has replaced the comma in KISS with an ampersand.

  • Anonymous (unregistered) in reply to Bim Job
    Bim Job:
    Casting to one side (er) ...

    The first two examples are very nearly perfect implementations of the venerable HP engineering adage, "Keep It Simple, Stupid!"

    The third example is, unfortunately, an anti-KISS.

    The problem with the first two examples is that the Senior Developer has replaced the comma in KISS with an ampersand.

    Oh my God, all these years I thought it was "Keep It Stupid, Simpleton!". I've been writing stupid code all this time and thinking it was a valid design strategy. Oh lord, 10 years worth of code to re-write...

  • ClaudeSuck.de (unregistered) in reply to remibourgarel
    remibourgarel:
    Cast<T>(this object obj, T type)

    is great if you want to return anonymous object from a method!

    this will crash if your object is null, and this new notation is a big fat and ugly bull######it.

    If you think the cast function is useful, you're the kind of person who create these functions :

    int Multiply(int i,int y) int Add (int i, int y) int Substract(int i,int y)

    Why do these stupid programmers create operator when we can create dozens of useless functions ?

    Well, you know, in embedded systems without a file system...

  • (cs) in reply to Zecc
    Zecc:
    Write in a language with no type safety at all, and casting will become a distant memory!

    As someone who's been writing to (and maintaining!) a fairly large perl codebase, I'm getting a kick out of your reply...

  • repeat of other posts (unregistered) in reply to TheCPUWizard
    TheCPUWizard:
    especially when considering re-factoring.
    Only if your refactoring tool sucks.
  • Anonymous (unregistered) in reply to repeat of other posts
    repeat of other posts:
    TheCPUWizard:
    especially when considering re-factoring.
    Only if your refactoring tool sucks.
    "Tool", hahahahahahahahaha!
  • Bim Job (unregistered) in reply to remibourgarel
    remibourgarel:
    Cast<T>(this object obj, T type)

    is great if you want to return anonymous object from a method!

    this will crash if your object is null, and this new notation is a big fat and ugly bull######it.

    If you think the cast function is useful, you're the kind of person who create these functions :

    int Multiply(int i,int y) int Add (int i, int y) int Substract(int i,int y)

    Why do these stupid programmers create operator when we can create dozens of useless functions ?

    Ah well, back to casting.

    The C++ implementation is a huge step forward, particularly if you code in emacs. (Doesn't everybody?)

    I can faintly see a justification in Java pre 1.5 (or whichever it was), where everything transmogrifies, in a sort of sub-Heisenberg way, into an Object and back again.

    I can't see any justification whatsoever in C#, which not only goes to great lengths to avoid the need, but is also invariably coded within a language-aware IDE. Disclaimer: I am not a C# programmer (or a Java programmer). I just think that the first code snippet has a peculiar smell; and that's without even considering exceptions (as above).

    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?

  • nobody (unregistered)

    I wish somebody would proofread the articles before posting :/

  • Chris McKenzie (unregistered)

    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.

  • (cs)

    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.

  • Matt (unregistered) in reply to nobody

    Proofreading is left as an exercise for the commenter.

  • Lawrence (unregistered) in reply to wee
    wee:
    Zecc:
    Write in a language with no type safety at all, and casting will become a distant memory!

    As someone who's been writing to (and maintaining!) a fairly large perl codebase, I'm getting a kick out of your reply...

    Indeed! Switch to perl and never cast again.

    Well almost never.

    If you really need to be sure it is a number (but why would you?) you can simply:

    $X = $X + 0;
    Or if you want a string:
    $X = $X . '';

  • aristos_achaion (unregistered) 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.

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

    TRWTF is using C++ as a good example.

  • (cs) in reply to ObiWayneKenobi
    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.

  • Doug (unregistered) in reply to frits
    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).

  • Chip (unregistered)

    In version 1, you cache the data.

    In version 2, you retrieve the data from cache and crow about how much faster it is.

  • Bim Job (unregistered) in reply to ObiWayneKenobi
    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.
    Welcome to the real world, kid. Magic Pixie Dust doesn't make IT any different.
  • (cs) in reply to Doug
    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.

Leave a comment on “Rendered Pointless”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article