Why we are a bunch of tough lovers.

Pages: 123
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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
#include <iostream>
#include <string>

using namespace std;
#define ABS(x) ((x)*((x)>0-(x)<0))
bool _(const string& __,unsigned ___=0.f){return(___<int(__.size()/(('L'-'O'+'L')%2*2)))?(__[___]==__[__.length()-___-(0xFE>>'\a')])?_(__,___+(0xFF>>ABS('F'-'U'-'C'+'K'))):___-___:!(0xFF>>010);}
#define __(___) cout << ___ << " is " << (_(___)?"":"not ") << "a palindrome."

int main()
{
    __("racecar");
    return 0;
}
Last edited on
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.

-Albatross
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.

-Albatross
Last edited on
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.
Last edited on
Alright. I updated the example and list of points somewhat. I hope I didn't make it too ugly...

-Albatross
It's quite painful to look at, but regrettably not the worst I have seen in this forum.
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.

-Albatross
You used new instead of malloc.
I actually thought about that... would a C++ newbie really use malloc() over new? If so, I'll change it, but that surprises me a little. <:O

EDIT: Then again, I did see one or two inappropriate uses of malloc here.

-Albatross
Last edited on
closed account (S6k9GNh0)
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.)
^Actually, it isn't a true superset.

C has VLAs, different struct semantics, long long, etc.
Maybe not a true superset, but the differences aren't really that big. And C++ has long long too?
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.
C has VLAs

IIRC, VLAs came to C in ISO C99, and C++ is 'based' on C90.
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.

The question wasn't if it's desirable or not, but if we can regard C++ as a superset of C.
I wonder if the state of C++ not being a true superset of the current C has changed with C++0x.

Similarly, I wonder how much C++ compatibility with C will be broken if C1X gets anywhere...

-Albatross
Somewhat. They added long long ints and some other things...I don't recall the details exactly however.
Pages: 123