IIRC if you have a local array on the stack like "int dst[10];" you have to use code like &dst[0] or you get a type mismatch, like "cannot convert int[10] to int*". I distinctly remeber being flustered about this in high school as i though that dst[i] was shorthand for (dst+i) and dst should match an int.

If it's C++ rather than C, then I think taking the address of element 0 would actually be in line with Stroustrup's original desire for the language. IIRC he wasn't keen on allowing array variables to decay implicitly to pointers, and only did so to keep C programmers happy. Or something along those lines anyway.

It's like that episode of Red Dwarf where they find the time machine and they go back to like the 15th century but since it's only a time machine and not a time-and-space machine they're still in the middle of nowhere and then their future selves pop in and they invite the future selves to dinner and when future-Rimmer enters their crappy-ass ship he screws up his face in disgust and goes, "can you believe we used to live like this!"

IIRC if you have a local array on the stack like "int dst[10];" you have to use code like &dst[0] or you get a type mismatch, like "cannot convert int[10] to int*". I distinctly remeber being flustered about this in high school as i though that dst[i] was shorthand for (dst+i) and dst should match an int.

So yeah i agree TRWTF is &(dst[0])

I have not had such problems, just memcpy(dst, src, len) work for me. Were you programming C++ in high school maybe it is different than C. I just used C

Just letting that void* return fall off into the guts of the computer is horribly irresponsible and I bet "len" isn't even a size_t! And you shouldn't blindly trust that len is smaller that the length of dst either...

-Wall turns on all normal warnings, if you want fun, you turn on -Wextra. But even then you're missing out on a few optional gcc warnings.

Thus the question, "what did they think the word 'all' meant?"

Wouldn't -Wnormal do the normal warnings? Then -Wall do *all* of them?

See, this is why I have trouble communicating with open source people-- open source people look at that and they're like, "oh no problem" and me, it drives me nuts.

That pretty much sums up my entire experience in the IT industry. Everyone thinks they did the right thing as long as it works. I can't tell you how many conversations I've had with developers where I said "The method that enables a user account is named 'DisableUser'" and they replied "Don't worry about it, it's used properly and no one filed a bug". It's just as bad in corporations as it is in open source.

If the entire IT industry suddenly switched to building bridges, I'd get rid of my car.

I think the best one is Win32's CloseWindow. Which will hide a window, making it for all appearances, closed. What you actually need is DestroyWindow. An easy mistake to make with no obvious consequence beside resource leak.

I think the best one is Win32's CloseWindow. Which will hide a window, making it for all appearances, closed. What you actually need is DestroyWindow. An easy mistake to make with no obvious consequence beside resource leak.

Yeah, but that mistake can't bite you unless you've already made the fatal mistake of Win32 programming.

(Although honestly that doesn't really strike me as wrong-- you can close a window without removing it from memory, that happens in tons of apps. Think about the Bookmarks window in a browser... there's nothing wrong with it existing in memory whether it's visible or not.)

It probably did do all of the normal things once. Then they invented a few more but didn't change -Wall because they didn't want to make the compiler incompatible with existing code. They could create a -Wall453 (say) option to include every warning that particular version supports, or they could reason that anyone who cares about code style that much will use lint anyway.

In any case, I for one am disappointed that nexekho forgot -ansi -pedantic (to flag up all those horrid // comments, apart from anything else).

Hiding a window is closing it, in GUI parlance. Is there a difference between the two?

Even in programming parlance, Closing a SQL connection is distinct from Destroying it. So... I don't see the problem with that function name.

OSX, afaik, is the only OS where closing a window does not exit the program. I'm not sure whether that's a UI fuckup of a twisted mind, or just really, really awkwardly implemented prefetch (as a running program can spawn its window faster, obviously).

So yeah, CloseWindow intuitively should exit the program; destroy the window rather than hiding it, and since it does not do that, from that standpoint it's poorly named.

OSX, afaik, is the only OS where closing a window does not exit the program. I'm not sure whether that's a UI fuckup of a twisted mind, or just really, really awkwardly implemented prefetch (as a running program can spawn its window faster, obviously).

If you really care, it's a historical thing... Mac OS started life as a single-tasking OS (well... that's not quite true, but we'll ignore Desk Accessories for the moment to keep things simple), meaning that only one program could be run at a time, and the currently-running program had full control of your screen. This was really painful from System 7 to System 9, when Mac OS gained proper multitasking (that is, two programs could be visible at the same time), but didn't have good enough virtual memory technology to swap-out running-but-not-being-used processes-- so accidentally leaving a program open, which was super-easy, could also bring your system to a swapfest crawl. By the time OS X rolled around, the VM was good enough that it didn't really matter if you left programs open or not, so it stopped being a problem.

So yeah, CloseWindow intuitively should exit the program; destroy the window rather than hiding it, and since it does not do that, from that standpoint it's poorly named.

Because every computer program on Earth can have only one window ever? Or is that a really subtle troll I'm not getting?

You can quibble (rationalize), but if it were "open source types" who had named this, you'd be all over it. In the windows world, "close the window" usually means to quit the program (yes, yes, not always, but c'mon, that's what we typically think of). Even so, here's what MSDN says (link guaranteed for seconds after posting):
@MSDN said:

I was under the impression that this part of the thread was devoted to badly named functions, rather than ones which do things no sane person would ever need. As CloseWindow hides a window, it counts.

Hiding a window is closing it, in GUI parlance. Is there a difference between the two?

Even in programming parlance, Closing a SQL connection is distinct from Destroying it. So... I don't see the problem with that function name.

I expect no less of you. I shall have to demur nonetheless.

In the context of inter-process communication, "close" always refers specifically to the connection. As the other side may close it for no clear reason, one wouldn't expect it to be any more destructive than necessary. In GUI programs, by contrast, closing usually implies losing the temporary data associated with whatever is being closed.

There is a bit more variety in programming. In some contexts, closing a window may be destructive (as in Javascript), or not used at all (as in X11 and Curses). The Win32 API uses Close to refer to an easily reversed action. It's a perfectly sensible name if the main context in which multiple windows are created is in a file manager where each window represents a directory, and the windows have little temporary data of their own anyway.

You can quibble (rationalize), but if it were "open source types" who had named this, you'd be all over it. In the windows world, "close the window" usually means to quit the program (yes, yes, not always, but c'mon, that's what we typically think of).

No it's not. Probably because I'm sane.

Closing the window and quitting the program are two entirely different things. Quitting implies closing, but not vice-versa.