- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Actually, 892 is an even interval!
Admin
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.
Take for instance the System.Collection.ArrayList constructor. You can create a new ArrayList with any of the following:
new ArrayList()
new ArrayList(int capacity)
new ArrayList(ICollection c)
Admin
In fact, the part Alex snipped includes the initialization of the string messageText to "Do you want fries with that?".
Admin
The worst (?) one I ever saw was from this person who was extremely intelligent, who created a project acronym that, for obvious reasons, never got used:
Common Library Internals Tying Original Real Income Server
My favorite almost-used name was for a company that wanted to have a way of tracking business prospects.
It was changed before deployment, but I still think "P-Tracks" is pretty bad.
Admin
Unfortunately, the C# method as described above involves more code for the function overloading.
Admin
Best one I ever saw was the Personnel Management System. We joked that the server would go down once a month.
It was later changed to the Personnel Record System.
Admin
Admin
They should have just said
/* JKF 1999-07-21 I hope this doesn't end up on TheDailyWTF */
Admin
I know of a major European airport that used to have a Passenger Information System. Honest.
Admin
What? This is garaunteed to segfault. Always. Every time.
(Maybe they meant this? COrderSummary obj; obj.XMLParse(...);)
Admin
and how do you turn it off? <g>
Admin
Admin
Better just stick to the wife.
Admin
I once heard that Sun found something like the following deep in the Solaris scheduler (they were taking a look at the code before handing it to some high paying customers):
Admin
Nah, the real problem is that the brain processes it as an inherent contradiction...Is it Enable or Disable? Sure, you look at it for a second, and you get it, but that kinda stuff builds up, and you end up with seriously unreadable code.
Admin
buttCheek = ass.split('|')[x]
Admin
Um, no, it wont... as long as no fields are accessed in the method.
The WTF here is that they bothered to comment the thing as "should be static" instead of sticking a freaking 'static' keyword on the front. If its a static method, declare it like one.
You would then call it as COrderSummary::XMLParse(someXMLString)
By not declaring it static, someone in the future might decide to access a member var in the code, which would cause all static usage of it to segfault. (or maybe randomly segfault based on whether the var was needed or not)
Anyway, much better to get a segfault than to get completely random behavior and possible memory corruption, which is what would happen if you call it without initializing the pointer and the method is no longer acting static.
Admin
Having been caught with my pants down one too many times managing a hosted PHP application, I wrote a function called DevMode() that returns true if the script is being run on the development server, false if not.
So then it would look something like:
if (DevMode())
if (SomeCondition)
syscall_beep();
That solves this problem once and for all!
Admin
More like score -1 for Office .NET objects... One of the biggest PITA to work with.
VB.NET isn't much better.
oExcelDoc = oExcel.Workbooks.Open(ExcelDocName, , True, , , , True, , , False, False, False, False)
Admin
No, sadly, it's not, because this is C++. If the method were virtual, it would segfault, but in C++ the method isn't virtual unless it's declared virtual. For non-virtual methods, you can do this (or at least not every compiler is going to kill you for it); but if the method dereferences the "this" pointer, or tries to access any data member (other than a static one), or tries to call a virtual method, then it will segfault.
Admin
I'm gonna get my Cumulative_Rate all over your Associated_Skill, bee-atch!
Admin
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#.
Alex's example in C#:
Admin
Here are a few funny names I've come across...
// S-curve lookup table
private byte[] sLut;
We also have a fingerprint scanning device from a manufacturer named Heimann. We've had many good laughs about this for years. The image quality is best if your fingers are not too dry, so we apply moisturizer to the fingers before scanning if there are problems. During a particular sales demo, my boss said to the client "Now that your finger is all lubed up, you can stick it in the Heimann".
Admin
That's why it's an exception.
Admin
It's not rare if you develop the right kind of driver. Just put your portal into protected mode and you'll be interfacing with the system internals in no time. Remember, it's not the size of the download that's important here, it's how you handle the buffer overflow...
Admin
Sounds like that intern rode the:
short bus;
to work.
Admin
A couple people have already corrected you, but there weren't any explanations for why things are as they are. Consider a C++ "compiler" that translates code into straight C instead of into some machine code. I don't know if any are still in common use, but the compiler Stroustrup worked on during the development of C++, CFront, at least worked like this. It's instructive to see what it does to common constructs. Consider a class:
class SomeClass {
int someData;
public:
int someMethod(int anArgument);
};
This would get translated by our CFront-like compiler into:
struct SomeClass {
int someData;
};
int SomeClass__someMethod(struct SomeClass* this, int anArgument);
In other words, it drops all the member functions out of the class declaration, as well as all the access modifiers. (It checks access separately; we won't consider that.) It then makes a prototype for each of the member functions as a free function that takes a pointer to the class as the first argument. (The name's also mangled, usually worse than what I show above.)
Now the implementation of functions:
int SomeClass::someMethod(int anArgument)
{
return someData * anArgument;
}
This would turn into:
int SomeClass__someMethod(struct SomeClass * this, int anArgument)
{
return this->someData * anArgument;
}
Anything that's a reference to a member variable is prefixed with "this->". Now how does a call get translated?
This:
SomeClass someObject;
someObject.someMethod(5);
Becomes:
SomeClass someObject;
SomeClass_someMethod(&someObject, 5);
And
SomeClass* somePointer = new SomeClass;
somePointer -> someMethod(5);
Becomes:
SomeClass* somePointer = malloc(sizeof(SomeClass));
SomeClass__someMethod(somePointer, 5);
Note that there's no dereferencing of somePointer in there at all. This means that if you say something like:
NULL -> someMethod(5);
(ignore that it would need a cast to tell it what type NULL is) then it will just be translated to:
SomeClass__someMethod(NULL, 5);
Again, no dereferencing. The only problem comes up in during the execution of someMethod, in that 'this' is NULL and the implementation dereferences 'this'.
If the function is conceptually static, then it doesn't access any member variables (and doesn't call any nonstatic functions either, which rules out anything virtual). This means that the compiler doesn't insert this-> before anything, so 'this' is never dereferenced.
You can play around with this if you'd like. You can actually get some pretty weird errors. For instance, if you do something like the above accidentally, and haven't seen the issue before, the fact that it gives an error about, say, address 0x4 being not readable when it's running someMethod might take some time to sort out.
Anyway, just one more aside: virtual functions. These are stored as function pointers inside the struct. So if someMethod was virtual, then SomeClass would be translated instead to:
struct SomeClass {
int someData;
int (* someMethod) (struct SomeClass* this, int anArgument)
};
and then the function call with pointers would be:
somePointer->someMethod(somePointer, 5);
(Note that somePointer is repeated here.) Thus HERE because it needs to access the someMethod field of *somePointer, if somePointer is NULL it will segfault.
(Actually, the description of virtual functions is a bit simplified from practice. In reality, a vtable is created for each class, and the pointers to virtual functions go in the vtable, not the individual objects. The objects then hold pointers to the vtable. There are a lot of efficiency reasons for this. However, implementing something like the above would be perfectly legal, AFAIK, according to the C++ spec.)
Also note that the above is just my understanding; I'm not a compiler writer, so I can't say that this is exactly how things are done in practice. However, I've read a lot about C++ that would affirm what I said and seen a lot of bugs that manifest themselves in a way that is consistant with the above and not much else, so I'm pretty confidant that this is at least a good approximation to what's happening.
Admin
I don't by default put blame at the author of that comment. There are a couple reasons.
First, the guy who originally wrote the method (which may or may not be the same person!) might not have understood or known about static methods. I can't decide if this is WTF-worthy. I'd LIKE to say it is, because static methods are something that aren't too difficult that seem to me like they should be in the arsenal of anyone programming C++ or Java... but I don't know how widespread exposure is. For instance, in my four years as an undergrad, I don't think I heard even once about static methods. This includes two semesters of C++ instruction. On the flip side, the dept is not exactly known for producing stellar programmers. It's not a terribly great department, and we've gotten comments from industry that we should improve instruction in programming itself. So it's possible that we're the exception in this.
Second, suppose either it's a different guy who made it non-static in the first place, or the same person but he's since expanded his toolkit to include static methods. It's possible that he's not in a position now to change it. If the class's use is widespread, then either he might be too lazy to change it (somewhat WTF-worthy) or not have the authority to change it.
In short, I think this IS a WTF, and belongs on this site, but at the same time I think it's one of the lesser ones that shows up here.
Admin
Ahem... Params[]
Captcha: awesomeness (previous was genius, when I forgot to click quote...)
Admin
Admin
[quote user="Anonymous"][quote user="BradC"][quote user="Alex Papadimoulis"]And while we're picking on the VS Tools for Office, following is the code required to call Excel's Dialog Show from C# ...
[/quote]
Ah, score one for VB.Net, which supports optional arguments.
Take that, C# !!!
[/quote]
Ahem... Params[]
Captcha: awesomeness (previous was genius, when I forgot to click quote...)
[/quote]Params[] doesn't even begin to address the same problem as optional arguments. While it IS possible to use params to give you optional arguments, there are a LOT of shortfalls.
Variable length argument lists are intended to solve an entirely different problem then are optional arguments.
Admin
Enable()
without the extraneousDisable
bit. If you want to enable/disable individual controls, you'd probably have to request them. That's the least surprising and most obvious behaviour.Admin
You don't have to use positional arguments. You can also do:
<FONT face="Courier New">oExcelDoc = oExcel.Workbooks.Open(FileName:=ExcelDocName, ReadOnly:=True, SomeOtherParam:=True)</FONT>
Don't try saying it's an awful syntax because C# uses the same syntax for assigning values to public fields on attributes.
System.Windows.Forms.MessageBox.Show is a good example of why optional parameters are better than overloading. There are 12 overloads and you still often have to fill in nulls in the best overload. Also, you can't use overloading to distiguish between calls using different parameters of the same type. This doesn't work:
<FONT face="Courier New">public DialogResult Show(string Message)
{
...
}
public DialogResult Show(string Title)
{
...
}</FONT>
A similar thing happens in the other direction. If you have a C# method with an unsigned long parameter, it can't be called from VB.Net. Each language has its little things that it does better than other languages.
But, can the C# guy please at least concede that VB.Net has optional arguments and C# does not and C# would be a better language if it did have them. You don't have to use them all the time, but they do come in handy.
BTW, the Office API was invented back when no language other than VBA could call it. So, it developed a lot of optional parameters because VBA didn't support overloading. That's why today it sucks to call it from C#.
Admin
it's the member function of a form object. true enables, and false disables. it operates on all of the control on the form...
forgive me if you were being sarcastic.
Admin
Yes it can - right click on the break point
Admin
WTF did that mean?
Admin
Seriously, dude. You need to get laid.
Admin
A bit more of a nitpick: string predates the STL, and in modern C++ it's std::string. It's just string if you're "using std", but class declarations are usually in header files and "using" namespaces in header files is usually a bad idea.
Admin
Did you ever tried to right-click on the red dot of a breakpoint?
Admin
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.
You could use some tracking classes, debug.writeln and similar things, but again, you're losing correlation between the events and actions that caused them, unless you're carefully watching at the clock and ... no, it's just hard to debug any GUI-related problems this way...
Admin
To be fair, that comment doesn't actually say the number wasn't there in the first place. It may have been that it was merely not properly labelled...
Admin
Long ago I was asked to create a pattern. I didn't know what it was supposed to be for and for some reason I couldn't get a good answer as to what it was supposed to be. Creating the graphics was no big deal but it needed a name. In my attempts to get a name the guy referred to it indirectly as "shit". (Something like "the shit you're working on"--it's more than a decade ago, I don't recall the details.) Only maintainence would ever see the internal name I gave it--so the object I created was named "shit".
No squawks once I explained where the name came from.
Admin
Something about this post and the "German variable name" discussion in another thread reminded me of a project years ago where we had database and server names based on Catch-22: development was on Yossarian, V&V was Nately, and so on (Nateley's Whore would not work because of the embedded chars). Anyone want to guess what we called the UAT database?
Admin
Admin
The real WTF is that C# doesn't support optional arguments. Even C++ can do that.
Admin
I'll nitpick you one better: It's either "using namespace std" or "using std::string", not "using std" (unless I have been misled all this time).
;)
Admin
I think this reasoning is BS. Perhaps I don't fully see the consequences here, but it seems to me that nothing they say there is a criticism of anything but the way they IMPLEMENTED default arguments in VB.
I see no reason why you couldn't have the C# compiler translate this:
int foo(int first, int second=default) { ... }
into this:
int foo(int first, int second) {...}
int foo(int first) { return foo(first, default); }
Automagically. As they don't seem to have a problem with the second form, voila, problem solved. You have a simpler syntax than writing the second thing by hand (and if you manage to define a function that takes thirty arguments like the show method in the original WTF, you don't have to write thirty overloads) but with the same result.
Admin
Certainly not. As long as you don't access members of the class, you can call any method, since it's been allocated with the classes' skeleton on the heap. No member accessed, no segfault, with most compilers at least.
Admin
yeah, the above post was a reply to this quote.
Admin
In the particular example given, overloading is indeed better than badly implemented optional parameters. I can also point out examples where composition is better than inheritance. Should we throw out inheritance, too?