if u ask me, if somebody asks for homewrk help, u post no code at all, but instead explain how to solve it step by step, that way the OP will need to write the code himself and he will (hpoefully ) learn something
The problem however, is that if they'd have done a little research of their own, they would have solved their problem in about 90% of the cases. I linked to tutorial pages that are on this damn webpage too often.
I agree however that in the other cases you have to explain rather than solve. As soon as he/she however doesn't show any sign of actually trying something themselves, I go around and post codes similar to this one:
Even giving step-by-step instructions is something I like to save for when it's really needed. With the what-to-do given to you, you don't learn how to think in whatever language you're writing in, which is a really beneficial skill when writing your own programs. You learn the syntax and semantics of the language, sure, but you don't learn how to be creative in it.
I'm considering taking the example I gave in the first post and liberally dousing it with concentrated unadulterated evil.
In other words, I'm considering taking the example I gave and reworking it so that it features a very large number of "evil" C++ features. The purpose of this would be to add another point which states that if someone with less-than-perfect coding practices gives a solution and the poor solution-searcher learns from it, it may be hard to unlearn the poor coding style.
Any objections? Naturally, I'd change I've changed the subject of the article somewhat.
I completley agree. The first one to come to mind is 'void main(...)' this kind of thing would serve as a perfect example of what you are trying to do. I think I've seen once or twice 'main(...)' declared without a datatype, but I'm not sure that would compile even with '-traditional-cpp' passed into the compiler.
Also include A LOT of unneccecary maybe even some depricated libraries. You sound like you want to give an example of some of the worst-stuff-with-the-best-intentions we've seen here, I don't think it would confuse anyone who actually takes their time to read the article if that's what you're worried about.
This list could go on and on and still look like a valid C++ program. I like this idea please run with it.
Alright... what did I forget? I deliberately chose not to use void* pointers, I couldn't fit in any reasonable #defines, and as for mucking around with <conio.h>... hmm. I could've fit that in.
The newbies that use malloc in C++ are generally those that believe should learn C before they learn C++ as one is just an extension of the other. As a result, you see malloc in C++ a lot more often than you should.
Technically, they are right though; C++ IS a superset of C. That's purely technical, though. Speaking practical, there - however - is quite a lot of occasions where both languages give their own typical (different) solutions. (Including differences like malloc and new.)
IIRC C++ doesn't actually have long long as part of the standard yet, though almost every major compiler (if not all) supports it anyway. It should be coming in as part of 0x though.
VLA = Variable Length Array? Who would want that? It sounds like a mess waiting to happen, we have an entire list of STL Containers that do the same thing in an Object Oriented apporach with ready to use algorithms.