Is It Really Possible to Learn C++ without knowing the details of C?

Hi,
I would know what you think about this.

There seems to be an idea that C++ can hide the details of C, to the point that many details can be overlooked.

That is right in principle but at some poi cout doesn't suffice, if you make a parser or some other details management tool.

Also hiding after understanding is different than hiding before understanding.

What is your opinion?

Thanks
There are now immense differences between C and C++, especially in the way you think and the way you write code. I have been studying C++ passionately for 5 years, and I can't write in C worth a darn.
Hi,
thanks for the reply.

The point I was at is :

Hiding after understanding is different than hiding before understanding.

Or would I need to be library dependent for everything?
Last edited on
Hi,
I do not understand:
I got this reply by email:
Thread: "Is It Really Possible to Learn C++ without knowing the details of C?"
Reply by: "Computergeek01"
Time of reply: Apr 4, 2014 at 4:42pm UTC

------------------------------------------------------------
I think for the first few years that it is beneficial for a student to
learn C++ as if it were a stand alone language. Like LB said,
there are so many drastic differences in the way you think between the
two languages that there is no benefit to learning C first if you're
primarily going to be working in C++.

First let's get rid of the notion that C++ is C with a bunch of added
bells and whistles. C++ is a separate language that happens to be
mostly compatible with C. Let's look at some examples:

1.) C has no concept of overloading and in fact it relies on
you to manage the names of all of your functions and data
members to make sure they are unique. C++ is going to mangle function
names even if it has no reason to and gives you namespaces to manage
the data types.

2.) The concept of polymorphism is a very powerful feature in C++ and
it really doesn't have a parallel tool in C. You could cast back and
forth between void pointers and data-types but that's really just a
work around and it still requires you to micro manage your data-types
within the functions.


But I cannot see here.
Anyway, I agree about this.

The point is that I need to understand the mechanics on which the building is built, i.e. what is to be abstracted, to abstract.

Probably is a limitation of mine. But I need to see what the compiler sees to build on the rest.

I like to forget the binary representation as long as I can recall it as needed.

Thanks for the reply.
Last edited on
All languages are "hiding". That is the point of a user friendly language instead of everyone trying to write machine language. Based on your point/question everyone would have to understand machine language before they could learn Assembly, and Assembly before they could learn..., etc, etc, up to a modern language. There is no point in all of that. You do not have to understand the under workings of something to be able to use it. Did you learn everything about how a car works before you drove one? Did you understand how a power plant produces electricity before you turned on a light in your house? Point is to learn the language that will do what you are trying to do best.

I also am in same situation LB is. I can do most things in C++. I struggle very much when tasked with something in C.

Hope this has helped.
@dalfonso01: we've recently had a discussion about bottom-up vs top-down education systems, and I think you might be used to the bottom-up approach used by most public school systems. It is actually better for you to use a top-down approach to learning - try it out and see how it goes ;)
Yes, it helped.

Probably is a limitation of mine. As I told, I just need to be able to reverse, not to have details present. But any way the knowledge of mechanics is something relevant to my interaction with the bare metal.

Thanks
Last edited on
I guarantee that if you focus on how something works instead of how to use it, you will end up being more confused.

The only important thing in programming is how to use the tools the language provides. How they actually work is of little to no importance. In fact, many compilers and operating systems do it in entirely different and incompatible ways.
LB wrote:
I guarantee that if ... In fact, many compilers and operating systems do it in entirely different and incompatible ways.

+1. that is how i learned. a great example is <string>'s getline. it seems simple enough to call. i looked at the source code and it seemed very confusing. so instead i just decided to learn where i should use that and where i should use other streams
I went somewhat backwards. I learned C++ then started writing in pure C.

Really, I find that learning C first can't hurt, outside of what others consider good practice. You should know what causes problems where and why things are considered bad practice before you do them though.
I'm with noxzema here. Not saying it's "better", but that's how I learned. I started in C++, and I was so confused when code wouldn't work as expected. I learned more about memory management in C, and write MUCH better C++ code now because of that. However, you may be totally different. I know what tools to use better when I know how they work. You could be totally different.

But yes. You can learn C++ without being a C programmer. The thought process is different.
Yeah, sorry I had deleted that post because I had to leave my desk and so I wouldn't be able to respond to anything you had written as a response. But seeing as you read it anyway I'll just pick up from your reply here: http://www.cplusplus.com/forum/general/128180/#msg693223

If you're curious about the under workings of your compiler and what the OS and your code are doing then I suggest skipping over C and start de-compiling your projects into assembly with your preferred debugger. This is something you will often have to do anyway so it kind of serves two purposes here.

Don't get discouraged about the amount of assembly code that is generated from a simple program, a LOT of it is just simple verbose stuff that gets included in every program (which is one reason we have mid to high level languages to begin with). Don't try to read it from the top to bottom for that very reason; just step through your normal program flow and see what your code is actually being compiled into. Then make a small change, recompile and see how much of a difference it made in the resulting binary. Read up on what 'lvalues' and 'rvalues' are and then see if you can tell the difference between them in the assembly code. You may want to read up on the different calling conventions that your program might use before diving into something like this. It will help you understand the program flow better. Now that I think of it, if you are going to do this it would probably be easier to start reverse engineering code that was written in C, that is unless you are comfortable with the concepts in C++ like name mangling and run-time evaluation.

NOTE_1: It might help to turn off ASLR while you're doing this if you are using a modern version of Windows or any version of Linux, otherwise the inconsistencies in the load addresses may cause some unnecessary confusion for you. UAC might also be a problem because of the SE_DEBUG privilege, I can't remember if it is an issue or not. Just remember to turn them back on when you are done experimenting.

NOTE_2: GCC and MingW have this "feature\setting" that is turned on by default where they won't compile the same line of code the same way twice, so without disabling that you will be spinning your wheels trying to get the hang of this stuff.
Last edited on
For advanced users C is better for low-level stuff, C++ is better for more complicated stuff.

For beginners, C is better for learning the basics of programming (while/for/if). This is what you should learn first. C++ is better for learning OOP (encapsulation, polymorphism), this is what you should learn second.

I've heard that the worst thing about C++ is the programmers. This is because people stop learning half-way between these two steps. Instead of writing pure low-level code or pure OOP, they use the worst of both worlds and that's something to avoid. If you want to get good, go all-out.
@ Stewbound: I can't say if I agree with you or not. Please clarify "low level" in the context of your post. I'm reasonably certain that I know what you mean, and that we agree on this term, but if you don't mind specifying your interpretation then doing so would help me.
Hi,
thanks for your replies.
I find that for myself I needed the point of view of NoxZema and BlakeK. I had some embarassing gap at beginning and understood it was related to char type and character arrays, because there was no clear understanding of the semantics of of the type so buffering and other things hided the one by one char processing and confusion grew.

After I saw the mechanics that directly or indirectly creates the behaviors, on cascade, all started to have a predictable result up to complex structures and compounds of char elements.

After all grammar, semantics and syntax are related by the design of the language and reflect the idea of the creator, what is to be granted is that the evolution is consistent, but the meaning is upfront arbitrary.
So if char would have a different semantics and grammar we would have a different way to express the same meaning for us (that's just as using another language).

I find for myself that having a root cause of behaviors gives me the confidence to understand the reason things are or were chosen in that way for what is being handled on top.

For example, this post has a maximum lenght of (max=8192) , the number is familiar.

I am starting seriously now to go into C++ (C) to become quite operative after an incubation period and I am doing this building a Pascal compiler on the track of Ron Mak book: Writing Compilers and Interpreters: An Applied Approach Using C++.

The code is a bit old, so I am first making it compatible to current C++ and later would make iterations to progressively use as much as possible C++ Standard Libraries and advanced techniques and patterns to make it better and robust.

On the other side, this is the typical matter where understanding the engine to make a better driver experience, is not really optional. I opened a github on this and later could be interesting to share some ideas by code.

Thanks for your replies.
Last edited on
Topic archived. No new replies allowed.