• Miral (unregistered) in reply to EvanED

    Any method that takes more than five or six parameters at most is a WTF in itself.

  • anonymous (unregistered) in reply to Miral
    Anonymous:
    Any method that takes more than five or six parameters at most is a WTF in itself.


    on langs with hash/dictionarys you can pass a array of parameters

    DrawString($string,array("color"=>"red","family"=>"sans","bold"=>true));

    has VBA dictionarys?

  • SadBugKiller (unregistered) in reply to qbolec
    qbolec:

    I used the beep-debugging many times, as it's great technique for tracing. Conditional breakpoints serve different purpose - they simply break the execution, which often means: break in the middle of receiving mouse input, kick back focus to the debugger, and obscure the whole application window with the debugger, causing Invalidate - this may, or may not, be what you need when debugging GUI issues.



    Just an idea - try tiling the application and debuger's windows - this way Invalidate (I hope by Invalidate you mean receiving WM_PAINT and friends) won't happen. This will not solve all your problems but it may help from time to time
  • Dazed (unregistered) in reply to Miral

    Anonymous:
    Any method that takes more than five or six parameters at most is a WTF in itself.

    That's pretty exaggerated. But I'll agree that if you find yourself writing a method with more than half a dozen parameters it's time to stop for a few minutes and ask yourself whether you are in fact using the best approach.

  • Dogman (unregistered) in reply to pete23

    How 'Front End' of you.   The clue is that it was a server process.

  • Dogman (unregistered) in reply to Dogman

    Anonymous:
    How 'Front End' of you.   The clue is that it was a server process.

    I meant the guy who commented on the beep thing - why didn't you just put a break line in the debugger.   Hell Sonny - when you grow into writing some real programs you will realise that not everything happens on your freaking desktop.

    Bleeping and wtiting things to debug logs is alive and well in child process land.

  • Barry OConnell (unregistered) in reply to juvenile

        For i = 1 To CumRate
           
            cnn.Execute ("INSERT ROD INTO asshole")
           
        Next i

     

  • (cs)

    And here's another variation -- in Fortran 90 -- of this from Richard Shaw ... 

    integer, parameter :: one_thousand = 250

    It must be in base 21.145591083961146480807893875815!

  • O’Brien (unregistered) in reply to VGR
    VGR:


    public class Winston
    {
        public static final int TWO_PLUS_TWO = 5;
    }

    static variables are instance variables! Windows is Linux! Oceania has always been at war with Iraq...

  • spellmaster (unregistered) in reply to Philbert Desanex
    Anonymous:
    juvenile:

    I get the abbreviation with initials, but what else does puhse stand for?

    Two syllables...pronounce it.

    Language of origin? Can you use it in a sentence please?

    let me try. "PEW" + hhhhh + "seh".

    While we're at it, how do YOU Pronounce WHQL?

  • spellmaster (unregistered) in reply to spellmaster
    Anonymous:
    Anonymous:
    juvenile:

    I get the abbreviation with initials, but what else does puhse stand for?

    Two syllables...pronounce it.

    Language of origin? Can you use it in a sentence please?

    let me try. "PEW" + hhhhh + "seh".

    While we're at it, how do YOU Pronounce WHQL?

    Ohh, thanks for the "explanation". Maybe if catching that wasn't such an exceptional condition...

  • (cs) in reply to bob
    Anonymous:

    >if(xlApp.Dialogs[Excel.XlBuiltInDialog.xlDialogOpen].Show(sTextName,
    >  Type.Missing

    NOW do we understand why optional params are a bad idea?? Over f'ing load the method, people, I think even VB.NET can handle that. Suppose this was just a COM wrapper though...

    Optional parameters are actually a good idea... when they are optional for real. These are not optional parameters in my book, since it's required to include them in your funcall.

    Anonymous:
    Anonymous:

    >if(xlApp.Dialogs[Excel.XlBuiltInDialog.xlDialogOpen].Show(sTextName,
    >  Type.Missing

    NOW do we understand why optional params are a bad idea?? Over f'ing load the method, people, I think even VB.NET can handle that. Suppose this was just a COM wrapper though...


    Yeah, COM is that chunk of Win16 that stubbornly refuses to die, giving up a steady stream of WTF from 1992 to present.

    On a vague tangent, I really wish I could find a compiler/preprocessor that supported named arguments in C,  C++, C#, or Java. Everytime I touch win32 code after a month or two elsewhere I come back and end up clueless as to what arguments are doing, especially surrounded by a random number of NULLs.

    I don't know if it's usable yet, but the Nice language (that runs on a JVM and -- i'm pretty sure -- is a superset of vanilla Java) has things like named and optional (default) parameters.

    It also has first-class functions (and anonymous functions), tuples and tuples unpacking, closures, nullable types, type inference, a much better type system (the NPE and ClassCastException are supposedly absent from any Nice program) and some other stuff.

    And it run on a 1.2 JVM

    Anonymous:
    On a vague tangent, I really wish I could find a compiler/preprocessor that supported named arguments in C,  C++, C#, or Java. Everytime I touch win32 code after a month or two elsewhere I come back and end up clueless as to what arguments are doing, especially surrounded by a random number of NULLs.

    This is actually fairly easy to do within the C++, C#, and Java languages.  Stroustrup gave an example in The Design and Evolution of C++, showing that named arguments weren't necessary.

    Hardly necessary, but awfully nice, and much easier to use (both as the creator of methods and as the user of the aforementioned methods) than that kind of boilerplate.

    Hell, even Ruby's lets-use-our-bizarro-hash-syntax-to-emulate-named-parameters is better (thank god it should be replaced by real named parameters in Ruby2 though)

    Anonymous:
    BradC:

    Ah, score one for VB.Net, which supports optional arguments.

    Take that, C# !!!



    I hope that was a joke. C# has method overloading which can make a method accept different sets of arguments. The optional arguments are not marked with an "optional" keyword, but it is the same effect.

    With 5 times more boilerplate...

  • (cs) in reply to masklinn

    Followup of

    masklinn:
    Anonymous:
    On a vague tangent, I really wish I could find a compiler/preprocessor that supported named arguments in C,  C++, C#, or Java. Everytime I touch win32 code after a month or two elsewhere I come back and end up clueless as to what arguments are doing, especially surrounded by a random number of NULLs.

    This is actually fairly easy to do within the C++, C#, and Java languages.  Stroustrup gave an example in The Design and Evolution of C++, showing that named arguments weren't necessary.

    Hardly necessary, but awfully nice, and much easier to use (both as the creator of methods and as the user of the aforementioned methods) than that kind of boilerplate.

    Hell, even Ruby's lets-use-our-bizarro-hash-syntax-to-emulate-named-parameters is better (thank god it should be replaced by real named parameters in Ruby2 though)

    Soustrup's method also limits the programming styles you can use as it forbids functional-style programming for example (put arguments in, get results out) and forbits any kind of useful return, as you unconditionally have to return a reference to your object for the chain to work.

  • Kevin (unregistered) in reply to BradC
    BradC:
    I think you've misinterpreted my comment.

    When creating your own stuff, method overloading is the preferred technique. But when CALLING someone else's code that uses optional parameters (like MS Office apps), in this case VB.Net is vastly superior to C#.



    Aha. I did misinterpret your comment. I thought you were saying C# has no support for optional arguments, which it does. Not being a VB developer, i did not realise it had that feature. My guess is that the compiler adds in empty values, because they appear to be required in the intermediate language, and thus C#. A very handy shortcut for ridiculously long argument lists.

    Thanks for explaining your comment. It makes a lot more sense now.

  • Kevin (unregistered) in reply to Kevin

    "I thought you were saying C# has no support for optional arguments, which it does."

    Just to clarify, i meant arguments can be made optional by overloading methods, which is not what BradC described.

  • John Public (unregistered)
    Alex Papadimoulis:

    David learned a new thing about C++ when trying to create an instance of COrderSummary ... 

    /* ***
 * XMLParse - returns an instance of COrderSummary or NULL on error
 * ***
 * Note: This should probably be a static method. Since it isn't, 
 *       you will need to reference it will a null object:
 *            COrderSummary *obj = NULL;
 *            obj = obj->XMLParse(someXMLString);
 * ***/
COrderSummary::XMLParse(const char *xml) { ... }

    Just a side note... although that's pretty horrific code, it's technically valid and will run fine as long COrderSummary has no virtual methods declared. The class would have no vtable, and hence, obj will not be dereferenced at runtime. This example would make a devious interview question.

Leave a comment on “Another Friday Smorgasbord ”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article