• (cs)

    return "This " + "is " + "a " + /* "brillant " + */ "comment!";

  • (cs) in reply to snoofle
    snoofle:
    return "This " + "is " + "a " + /* "brillant " + */ "comment!";

    May I be the first to say: StringConcat("Not ", "even ", "close ", "f*cking ", "idiot", "!");

    Gives a whole new meaning to stripping bad words...

  • Sleepy (unregistered)

    Hmmm... didn't really pay attention in programming class, because the teachers usually couldn't remember how to log in... but wasn't there one group that was always telling us to use functions wherever possible? Functional programming is better than procedural, or something like that?

  • Todd (unregistered) in reply to Sleepy
    Sleepy:
    Hmmm... didn't really pay attention in programming class, because the teachers usually couldn't remember how to log in... but wasn't there one group that was always telling us to use functions wherever possible? Functional programming is better than procedural, or something like that?

    I'm not sure I'd call a concat method that ignores one of its parameters "functional".

  • (cs) in reply to Todd
    Todd:
    Sleepy:
    Hmmm... didn't really pay attention in programming class, because the teachers usually couldn't remember how to log in... but wasn't there one group that was always telling us to use functions wherever possible? Functional programming is better than procedural, or something like that?

    I'm not sure I'd call a concat method that ignores one of its parameters "functional".

    Dysfunctional is more accurate.

  • Larry (unregistered) 
    $ perl
sub StringConcat { "@_" }
print &StringConcat ("There's", "always", "another", "way");
There's always another way
  • (cs)

    throw new NotSupportedException("Paul G.");

  • Anon (unregistered)

    The genius part of it is that if you use it to concatenate two string literals, it will (presumably) stop the pesky compiler from optimizing it!

  • (cs) in reply to Larry
    Larry:
    $ perl sub StringConcat { "@_" } print &StringConcat ("There's", "always", "another", "way"); There's always another way

    err... I'm not a perl programmer, but wouldn't this return "There'salwaysanotherway"?

  • Tim (unregistered) in reply to Larry

    that pretty much sums up all that's good and bad about perl

  • Larry (unregistered) in reply to ContraCorners
    ContraCorners:
    Larry:
    $ perl sub StringConcat { "@_" } print &StringConcat ("There's", "always", "another", "way"); There's always another way

    err... I'm not a perl programmer, but wouldn't this return "There'salwaysanotherway"?

    Well, I cut and paste from my terminal window, I suppose you could do the same.

    Just call it one of those weird but frequent cases where Perl does what (it thought) you wanted, not necessarily what you expected.

  • revenant (unregistered)

    It's such a pity C# doesn't support default parameters. Or else code author might have written

    public string StringConcat(string param0, string param1, string param2="")
{
   return param0 + param1 + param2;
}
public string StringConcat(string param0, string param1,
   string param2, string param3, string param4, string param5="")
{
   return param0 + param1 + param2 + param4 + param5;
}

    thus supporting 2 and 4 parameters as well while reusing existing code. Best coding practices!

  • (cs) in reply to ContraCorners
    ContraCorners:
    Larry:
    $ perl sub StringConcat { "@_" } print &StringConcat ("There's", "always", "another", "way"); There's always another way
    err... I'm not a perl programmer, but wouldn't this return "There'salwaysanotherway"?
    No.

    You're thinking of 'print @;' as opposed to 'print "@";'.

  • Alun Harford (unregistered) in reply to revenant

    C# does now support default / optional parameters. It's a 'new' feature of C# 4.

  • ch. (unregistered)

    in OOP those two "simple tests" will be often violated in favor of a more refactorable / extendable / inheritable etc. code

  • (cs) in reply to Sleepy
    Sleepy:
    Hmmm... didn't really pay attention in programming class, because the teachers usually couldn't remember how to log in... but wasn't there one group that was always telling us to use functions wherever possible? Functional programming is better than procedural, or something like that?
    Oh yes, and you should ALWAYS reinvent the wheel as well! I remember specifically having my teachers tell us to always redo what has already been done for you.

    I mean why use String str = "this" + " code" + " sucks"; when you could have a BRILLIANT method to do this for you!

    You should either change professions or go back to school. I'ld prefer if you did option A personally.

  • RBoy (unregistered)

    Quick! Let's dissemble his car!

  • Sleepy (unregistered) in reply to amischiefr
    amischiefr:
    Sleepy:
    Hmmm... didn't really pay attention in programming class, because the teachers usually couldn't remember how to log in... but wasn't there one group that was always telling us to use functions wherever possible? Functional programming is better than procedural, or something like that?
    Oh yes, and you should ALWAYS reinvent the wheel as well! I remember specifically having my teachers tell us to always redo what has already been done for you.

    I mean why use String str = "this" + " code" + " sucks"; when you could have a BRILLIANT method to do this for you!

    You should either change professions or go back to school. I'ld prefer if you did option A personally.

    How 'bout I do both: go back to school, and start my new career as a teacher!

  • (cs)

    The real WTF is he did not use Extension Methods

    public static string StringConcat(this string param0, string param1, string param2) { return param0 + param1 + param2; }

    "So ".StringConcat("much ", "better!");

  • Jamie (unregistered)

    StringConcat("DELETE ", "FROM ", table, " WHERE id=:id", ";");

  • Jamie (unregistered)

    public string StringConcat(string param0, string param1, string param2, string param3, string param4, string param5) { return StringConcat(StringConcat(param0, param1, param2), param4, param5); }

    Optimized!

  • (cs)

    Using built-in functions are fine if you want to write code that is not portable and will probably be obsolete in 2 years. I on the other hand have taken measures to make sure my code lasts longer than other peoples. We disallow the use of the Imports statement (or "using" if you are a C# snob) because we DON'T OWN THE SOURCE CODE for those functions contained in those libraries. It is much more portable to write a StringConcat function that you have the ability to maintain than to use someone else's proprietary version of String Concatenation. Also, it lets you tailor the implementation to your specific system. I ngen all of my libraries so they are highly optimized versus the ones that come with .NET.

    So the moral is it is not a bad thing to write your own version of built in functions, because the built in ones are there more or less for demonstration purposes.

  • (cs) in reply to TopCod3r
    TopCod3r:
    So the moral is it is not a bad thing to write your own version of built in functions, because the built in ones are there more or less for demonstration purposes.
    You can use them to build your unit test cases against as well!!
  • BottomF33d3r (unregistered)

    Uh oh, hide the babies, he's back!

  • Steve (unregistered) in reply to TopCod3r
    TopCod3r:
    Using built-in functions are fine if you want to write code that is not portable and will probably be obsolete in 2 years. I on the other hand have taken measures to make sure my code lasts longer than other peoples. We disallow the use of the Imports statement (or "using" if you are a C# snob) because we DON'T OWN THE SOURCE CODE for those functions contained in those libraries. It is much more portable to write a StringConcat function that you have the ability to maintain than to use someone else's proprietary version of String Concatenation. Also, it lets you tailor the implementation to your specific system. I ngen all of my libraries so they are highly optimized versus the ones that come with .NET.

    So the moral is it is not a bad thing to write your own version of built in functions, because the built in ones are there more or less for demonstration purposes.

    I believe TopCod3r has just jumped the shark.

  • Mike Dimmick (unregistered)

    Given that .NET has String.Concat already, since version 1.0, this entire snippet is pointless, if it is C#.

    Incidentally .NET has three overloads that take two, three, and four string arguments respectively, and one which takes a params string array. Presumably the calling convention is more efficient with four parameters than constructing an array of four strings, but it tips the other way with five. C# programmers should also know that the compiler converts consecutive '+' operations to a call to String.Concat anyway.

    It could be Java, of course, which only gained variable argument lists quite recently - they appear in the Third Edition of the Java Language Specification (2005, Java 5 IIRC), where they are spelled e.g.:

    public static string StringConcat(string... params)

  • (cs) in reply to TopCod3r
    TopCod3r:
    Using built-in functions are fine if you want to write code that is not portable and will probably be obsolete in 2 years. I on the other hand have taken measures to make sure my code lasts longer than other peoples. We disallow the use of the Imports statement (or "using" if you are a C# snob) because we DON'T OWN THE SOURCE CODE for those functions contained in those libraries. It is much more portable to write a StringConcat function that you have the ability to maintain than to use someone else's proprietary version of String Concatenation. Also, it lets you tailor the implementation to your specific system. I ngen all of my libraries so they are highly optimized versus the ones that come with .NET.

    So the moral is it is not a bad thing to write your own version of built in functions, because the built in ones are there more or less for demonstration purposes.

    I just wanted to say "you're an idiot". Then I saw you're TopCod3r... Well, I haven't read the comments for a while, but last I saw you had apparently been banned. Well, welcome back.

  • (cs) in reply to Sleepy
    Sleepy:
    Hmmm... didn't really pay attention in programming class, because the teachers usually couldn't remember how to log in... but wasn't there one group that was always telling us to use functions wherever possible? Functional programming is better than procedural, or something like that?
    using functions in procedural programming != functional programming..
  • Infinite Quality (unregistered)

    StringConcat ('But ', StringConcat ('why ', StringConcat ('not ', StringConcat ('support ', StringConcat ('infinite ', StringConcat ('params ', StringConcat ('with ', StringConcat ('one ', 'function?'))))))))

  • Kyre (unregistered) in reply to A Nonny Mouse

    Using bad functions is not functional or elegant.

  • Mike Dimmick (unregistered) in reply to TopCod3r

    I really, really hope you're a troll, because if not you're a bit of an idiot.

    .NET runs ngen on all of its own assemblies when it's installed. .NET 2.0 installs a service - .NET Runtime Optimization Service - that can rebuild native assemblies when a patch is installed.

    I doubt very much that you can do better than the built-in implementation of String.Concat, which involves a trip into the C++ portion of the CLR to allocate a string of specific length, then some string copying by pointer arithmetic, using a partially-unrolled loop to copy 8 characters at a time.

    Sometimes you can beat the built-in implementation if it's a general one that has to cover corner cases that you're not interested in. But Microsoft have aimed to make it generally usable and suitably performant for the most common cases, precisely so that you don't have to reinvent basic functionality.

  • Mike Dimmick (unregistered) in reply to Mike Dimmick
    Mike Dimmick:
    I really, really hope you're a troll, because if not you're a bit of an idiot.

    .NET runs ngen on all of its own assemblies when it's installed. .NET 2.0 installs a service - .NET Runtime Optimization Service - that can rebuild native assemblies when a patch is installed.

    I doubt very much that you can do better than the built-in implementation of String.Concat, which involves a trip into the C++ portion of the CLR to allocate a string of specific length, then some string copying by pointer arithmetic, using a partially-unrolled loop to copy 8 characters at a time.

    Sometimes you can beat the built-in implementation if it's a general one that has to cover corner cases that you're not interested in. But Microsoft have aimed to make it generally usable and suitably performant for the most common cases, precisely so that you don't have to reinvent basic functionality.

    Dang, that was meant to be a reply to TopCod3r.

  • Brandon (unregistered)

    What I really like is that it's a static number of parameters. I mean, what if I wanted to contatenate the following...

    This is a six word sentence

    I couldn't do it. I'd have to write a whole new function!

  • Infinite Quality (unregistered) in reply to Mike Dimmick
    Mike Dimmick:
    Mike Dimmick:
    I really, really hope you're a troll, because if not you're a bit of an idiot.
    Dang, that was meant to be a reply to TopCod3r.
    You must be new here.
  • (cs)

    Reverse operator overloading -- nice. I look forward to ROO becoming the hot new programming "paradigm".

  • (cs) in reply to TopCod3r
    TopCod3r:
    Using built-in functions are fine if you want to write code that is not portable and will probably be obsolete in 2 years. I on the other hand have taken measures to make sure my code lasts longer than other peoples. We disallow the use of the Imports statement (or "using" if you are a C# snob) because we DON'T OWN THE SOURCE CODE for those functions contained in those libraries. It is much more portable to write a StringConcat function that you have the ability to maintain than to use someone else's proprietary version of String Concatenation. Also, it lets you tailor the implementation to your specific system. I ngen all of my libraries so they are highly optimized versus the ones that come with .NET.

    So the moral is it is not a bad thing to write your own version of built in functions, because the built in ones are there more or less for demonstration purposes.

    Welcome back.

  • (cs) in reply to TopCod3r
    TopCod3r:
    <snip> So the moral is it is not a bad thing to write your own version of built in functions, because the built in ones are there more or less for demonstration purposes.

    Well there actually is a legitimate reason for this kind of stuff at certain times.

    Game engine I'm working on has to be both DX9 and DX10 capable and which one to use is decided at runtime, not compile time. That way a Vista user can automatically get DX10 (if supported by hardware), XP user automatically gets DX9.

    Now DirectX does ship with the handy D3DX libraries with lots of functions needed for your basic 3D math (vectors, matrices, quaternions, etc.) However DX9 and DX10 both each have their own versions. DX10 libs may have functions DX9 libs don't. I can't also guarantee that DX9 libs may not have functions that aren't going to be replaced by something else in DX10 libs.

    So in my case, I actually do have my own Vector, Matrix, Quaternion, etc. classes because that way I'm API version independent. May also be of future benefit for cross-platform if OpenGL ever manages to fix their version 3.0 fuckup and becomes a viable alternate implementation.

  • jonny five (unregistered) in reply to Sleepy
    Sleepy:
    2. whatever the function does shouldn't be the same as a built-in operator
    I've been taught the idea that rule number 2 isn't always true. Sometimes it's better to extract a method when doing so provides better readability of code. The basic example they always use is to take this code: 
    if (number % 2 == 0){
  do something...
}
    and refactoring it to this: 
    if (isEven(number)){
  do something...
}
...
boolean isEven(number){
  return number % 2 == 0
}
  • iToad (unregistered) in reply to Brandon
    Brandon:
    What I really like is that it's a static number of parameters. I mean, what if I wanted to contatenate the following...

    This is a six word sentence

    I couldn't do it. I'd have to write a whole new function!

    Go for it. If you work anywhere where you are evaluated by lines of code produced or source code checkins, you can expect a nice bonus at the end of the year.

  • Matt (unregistered)

    param3 left with W and Y from yesterday's WTF.

  • yah (unregistered) in reply to Kermos
    Kermos:
    TopCod3r:
    <snip> So the moral is it is not a bad thing to write your own version of built in functions, because the built in ones are there more or less for demonstration purposes.

    Well there actually is a legitimate reason for this kind of stuff at certain times.

    Game engine I'm working on has to be both DX9 and DX10 capable and which one to use is decided at runtime, not compile time. That way a Vista user can automatically get DX10 (if supported by hardware), XP user automatically gets DX9.

    Now DirectX does ship with the handy D3DX libraries with lots of functions needed for your basic 3D math (vectors, matrices, quaternions, etc.) However DX9 and DX10 both each have their own versions. DX10 libs may have functions DX9 libs don't. I can't also guarantee that DX9 libs may not have functions that aren't going to be replaced by something else in DX10 libs.

    So in my case, I actually do have my own Vector, Matrix, Quaternion, etc. classes because that way I'm API version independent. May also be of future benefit for cross-platform if OpenGL ever manages to fix their version 3.0 fuckup and becomes a viable alternate implementation.

    You are surely attempting to out-troll TopCod3r - good luck with that.

  • bottomCoder (unregistered)

    public string Concat(params string[] arg) { var stringBuilder = new StringBuilder(arg.Sum(s => s.Length)); foreach (string s in arg) { stringBuilder.Append(s); } return stringBuilder.ToString(); }

  • Kuba (unregistered)

    (concatenate 'string "foo" "bar" "baz") "foobarbaz"

    But also

    (+ 1 2 3 4 5) 15

    Nothing new under the sun after you learn LISP, that is :)

    OTOH, I am now very much a believer in requiring LISP in all undergrad CS education: it does broaden your horizons, so that you at least look for features that can potentially exist in the language you have to work with.

    People who have no clue as to what may be reasonably expected of a programming language never look for those features, and end up producing their own polygonal approximations of a wheel.

    Cheers, Kuba

  • Alex (unregistered) in reply to jonny five
    jonny five:
    Sleepy:
    2. whatever the function does shouldn't be the same as a built-in operator
    I've been taught the idea that rule number 2 isn't always true. Sometimes it's better to extract a method when doing so provides better readability of code. The basic example they always use is to take this code: 
    if (number % 2 == 0){
  do something...
}
    and refactoring it to this: 
    if (isEven(number)){
  do something...
}
...
boolean isEven(number){
  return number % 2 == 0
}

    I think you're correct. However, what the post kind of implies to me at least is that it would be wrong to do:

    function isZeroMod(number, modVal){
  return number % modVal;
}

    Just like this wouldn't be an as bad form of this function (in my opinion):

    function createTableTag(class, cellpadding, cellspacing){
  return ";
}

    If that makes sense to use.  It keeps some of the literal values contained in the function, same as your isEven function.
  • Alex (unregistered)

    Blargh... Coffee gods haven't visited me yet. That isZeroMod function should be renamed or changed to

    return (number % modVal) == 0;
  • Anonymous (unregistered) in reply to Kyre
    Kyre:
    Using bad functions is not functional or elegant.

    Yeah, well maybe you want to write that gddmn login page yourself, hmm?

    CM

  • Haskell (unregistered)

    unwords ["This","is","neat."] or, if you don't want spaces, concat ["This","less."]

  • (cs) in reply to jonny five
    jonny five:
    Sleepy:
    2. whatever the function does shouldn't be the same as a built-in operator
    I've been taught the idea that rule number 2 isn't always true. Sometimes it's better to extract a method when doing so provides better readability of code. The basic example they always use is to take this code: 
    if (number % 2 == 0){
  do something...
}
    and refactoring it to this: 
    if (isEven(number)){
  do something...
}
...
boolean isEven(number){
  return number % 2 == 0
}

    If you don't think number % 2 == 0 is readable as determining wether number is even or not, you shouldn't write any code other than Visual Basic.

  • (cs) in reply to Mike Dimmick
    Mike Dimmick:
    Dang, that was meant to be a reply to TopCod3r.

    Well, there's your problem right there.

  • relaxing (unregistered)

    the real wtf is java overloads the + operator, but won't extend that same convenience to the users of the language.

Leave a comment on “Where'd param3 Go?”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article