C First?

Started by
48 comments, last by All8Up 12 years, 3 months ago

I think pointers are important because they give you an insight into what's really happening behind the scenes that you wouldn't otherwise get, but yeah - defer them a little, perhaps.

I want to talk a bit about pointers...

Assuming you wait long enough, most of the C++ threads on this site end up linking to my quizes (you've waited long enough). There's a reason for that: Most people who attempt my tests (without cheating) FAIL them. Even the easiest one, which is the first one.

When you speak of pointers as a magical thing that gets you down to the hardware, you're wrong. The fact of the matter is that in a modern application on almost any non-embedded platform A POINTER points "somewhere," not to memory. The fact of the matter is that in this day and age your program could be run on an emulated system, a virtual machine, across a network, from a TAPE DRIVE. A pointer could point to any of those devices and YOU, the programmer, would never know. A pointer could point to disk storage via memory-mapped files (mapping address space to file space), or to a network device, or even to memory on the GPU. The fact of the matter is, a POINTER, even in a pure assembly language program, is really just "something".

Now, you hear a lot of talk about how powerful pointers are. What people are really talking about are things like this:

int offset = (int)(T*)1 - (int)(MyType*)(T*)1;
aThing = (T*)((int)this + offset);

You hear people talking about how they "went hardcore C++ and pointer-ed dat shit up, yo." That's not being hardcore, that's not even being smart. That's flat out WRONG code, and is the EXACT REASON people should avoid pointers except when absolutely necessary.

Then you start getting into the more interesting foibles of C++... such as array to pointer decay. An example of this is the following code:

int productOf(int arr[3]) {
int product = 1;
for(int i=0; i<sizeof(arr)/sizeof(int); i++)
{
product = product * arr;
}

return product;
}

int main() {
int arr[] = { 1, 2, 3 };
std::cout << productOf(arr);
}

This catches many (all) newbies off guard. "Why does this print 1," they say. "Shouldn't it print 6?"


I'm wary of the talk of "idiomatic C++" - surely the objective is to write useful programs that (mostly, at least) work rather than to be particularly idiomatic? Something is also ringing the Fred Brooks/"No Silver Bullet" bell in the back of my brain here too...

So you also avoid using forks, spoons, and knives when eating right? Because you know... you can eat hot soup with your fingers. Idiomatic C++ is C++ that most people (who know C++) can understand. It doesn't mean you have to template the hell out of your code, it means that you should use those containers, algorithms, and functions provided when appropriate. Avoiding std::vector "because pointers work too" is just stupid.

In time the project grows, the ignorance of its devs it shows, with many a convoluted function, it plunges into deep compunction, the price of failure is high, Washu's mirth is nigh.

Advertisement
I would edit my reply, but I can't because the forum software is being retarded about the formatting.

So you also avoid using forks, spoons, and knives when eating right? Because you know... you can eat hot soup with your fingers. Idiomatic C++ is C++ that most people (who know C++) can understand. It doesn't mean you have to template the hell out of your code, it means that you should use those containers, algorithms, and functions provided when appropriate. Avoiding std::vector "because pointers work too" is just stupid.

I also mean to say: That doesn't mean "don't use pointers." It means "use them when appropriate."

In time the project grows, the ignorance of its devs it shows, with many a convoluted function, it plunges into deep compunction, the price of failure is high, Washu's mirth is nigh.


[quote name='Slavik81' timestamp='1328728951' post='4911002']
int arr[] = { 1, 2, 3, 4 };
int product = 1;
for(int i=0; i<3; i++)
{
product = product * arr;
}
std::cout << product;


"Why doesn't this produce 24?"
[/quote]
That's a good question.


[quote name='Slavik81' timestamp='1328728951' post='4911002']
int arr[] = { 1, 2, 3 };
int product = 1;
for(int i=0; i<4; i++)
{
product = product * arr;
}
std::cout << product;


"Why does this crash? Shouldn't it print 6?"
[/quote]
Also a great question.


[quote name='Slavik81' timestamp='1328728951' post='4911002']
int arr[] = { 1, 2, 3 };
int product = 1;
for(int i=0; i<sizeof(arr); i++)
{
product = product * arr;
}
std::cout << product;


"Why does this print <garbage goes here>?" or "Why does this crash?"
[/quote]
Ok question. sizeof is not something that should immediately be taught or used.

Those sorts of questions highlight fundamental concepts that the beginner doesn't understand. The fact that they might have those sorts of questions is not a bad thing. If you can coax out those misunderstandings in an otherwise simple environment, they are better off.

Just teaching a different way in order to avoid those issues doesn't help. They'll still have the same misconceptions and misunderstandings, but they won't know it. It's better to flush out conceptual mistakes early.

They need to know just enough syntax and language-specific knowledge to represent the basic concepts and play with them. Only once those concepts are understood should you move out into more expressive syntax, built-in libraries, and other more complex things. In fact, for itself is more complicated than need be. while and if are sufficient for an absolute beginner in the first lesson or two.




When learning C++ you should focus on learning C++. The C++ language is all of it, including the standard library. Pointers are and arrays are topics that can be delayed initially in favor of standard library containers. Get the good habits built, then show them the alternatives. All of the above loop issues are solved by the simple loop:

To learn programming in C++, you should focus on learning programming first. Learning C++ comes second.

Saying something like "my program must be correct, it's idiomatic C++" (which is the direction this discussion is going in)

Only if you want to deliberately take people out of context.

[quote name='Slavik81' timestamp='1328728951' post='4911002']
int arr[] = { 1, 2, 3, 4 };
int product = 1;
for(int i=0; i<3; i++)
{
product = product * arr;
}
std::cout << product;


"Why doesn't this produce 24?"
[/quote]
Because you are only multiplying the first 3 elements. Learn to use a debugger to see what's going on.


int arr[] = { 1, 2, 3 };
int product = 1;
for(int i=0; i<4; i++)
{
product = product * arr;
}
std::cout << product;


"Why does this crash? Shouldn't it print 6?"
[/quote]
You are accessing an element past the end of the array, which you are not allowed to do. Learn about undefined behavior.


int arr[] = { 1, 2, 3 };
int product = 1;
for(int i=0; i<sizeof(arr); i++)
{
product = product * arr;
}
std::cout << product;


"Why does this print <garbage goes here>?" or "Why does this crash?"
[/quote]
Because sizeof() gives you the size in bytes, which is probably not what you want.


int arr[5000000];
int product = 1;
for(int i=0; i< WHAT GOES HERE?!?!?!?!; i++)
{
product = product * arr;
}
std::cout << product;


"I want to be able to enter numbers and then when I stop display the numbers entered and then the product. How can I do that with my array?"
which would then be followed by
"Why does this crash immediately when I try and run it?!?!?!??!?!"
[/quote]
This is a perfect opportunity for you to learn about containers. If you are too new to programming, you can consider this to be a slightly advanced topic and you'll learn about it later.

Making these mistakes and understanding how to fix them is a very important part of becoming a programmer. If you start to learn C++ by using "magic" that hides all the details, you just won't know what's going on. In particular, you'll have no intuition for how long different operations will take, or how much memory is being copied around.

When learning C++ you should focus on learning C++. The C++ language is all of it, including the standard library. Pointers are and arrays are topics that can be delayed initially in favor of standard library containers.[/quote]
C++ is freaking humongous and learning all of it can be overwhelming to a beginner.

Get the good habits built, then show them the alternatives. All of the above loop issues are solved by the simple loop:


for(size_t i = 0; i < arr.size(); ++i) {
product = product * arr;
}

[/quote]
"Why do I get this error message?
error: request for member ‘size’ in ‘arr’, which is of non-class type ‘int [3]’"

"If arr is a std::vector<int>, is there is a guarantee that size_t is the correct index type, or should I use std::vector<int>::size_type?"

Beginners will make mistakes. If they start working at a higher level, they will make different types of mistakes, and they will have much less of a chance of understanding what's going on. They will also enjoy fun page-long compiler error messages.
One thing that gets me about a lot of these posts is that they're approaching this from the direction of C or C++ as a first language for programming, which is a horrible idea for both languages. A lot of the arguments used on both sides aren't particularly applicable if someone learns programming with an actual sane language first and only then goes after C or C++.

One thing that gets me about a lot of these posts is that they're approaching this from the direction of C or C++ as a first language for programming, which is a horrible idea for both languages. A lot of the arguments used on both sides aren't particularly applicable if someone learns programming with an actual sane language first and only then goes after C or C++.


I learned BASIC, Logo, Z80 assembly, x86 assembly and Turbo Pascal before learning C. C didn't seem particularly insane to me. Perhaps there are better options today, but I don't think it's crazy to learn C first.

One thing that gets me about a lot of these posts is that they're approaching this from the direction of C or C++ as a first language for programming, which is a horrible idea for both languages. A lot of the arguments used on both sides aren't particularly applicable if someone learns programming with an actual sane language first and only then goes after C or C++.


This.
1000000000x this.

Practically every reply 'defending' avoiding the core features of C++ is 'ah, but for a beginner...' and frankly a beginner in programming should be no where near C++; they shouldn't even be in the same room as a C++ Book until they understand how to program with something else.

And avoiding the C++ Standard Library while learning just leads to someone not knowing about the standard library; yesterday at work my line manager came in and started making happy noises about C++11 features (auto and lambda) and how useful they would be. During out discussion it became apprently that despite being in the industry longer than me, being a couple of years younger than me and generally being a very good game programmer he had basically no idea about the Standard Library algorithms at all.

Not learning it up front means that, unless you put the effort in, you are unlikely to ever learn it and avoid them. This forum has a scary number of people who claim to 'know C++' yet probably no nothing about the Standard Library of the language they profess to learn. It seems to be a uniquely C++ thing as well; C# programmers, Java programmers, even C programmers.. they don't avoid their standard library for no good reason... yet C++ programmers seem to wear it as a badge of pride.

Personally I consider anyone who avoids the Standard Library for their language of choice without a damned sound technical reason is an idiot.

I learned BASIC, Logo, Z80 assembly, x86 assembly and Turbo Pascal before learning C. C didn't seem particularly insane to me. Perhaps there are better options today, but I don't think it's crazy to learn C first.


Well yes, because you learnt BASIC, Logo, Z80, x86 and Pascl before C... you knew how to program because you learnt with something easy to program with aka BASIC.

One thing that gets me about a lot of these posts is that they're approaching this from the direction of C or C++ as a first language for programming, which is a horrible idea for both languages. A lot of the arguments used on both sides aren't particularly applicable if someone learns programming with an actual sane language first and only then goes after C or C++.

What do you mean by 'a sane language'?

This topic is closed to new replies.

Advertisement