Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1369584 Posts in 64365 Topics- by 56384 Members - Latest Member: multimedia.capitalworks

November 22, 2019, 01:39:52 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)Should I learn C before C++?
Pages: [1] 2
Print
Author Topic: Should I learn C before C++?  (Read 1113 times)
arjunkumar
TIGBaby
*


View Profile
« on: July 11, 2019, 11:01:17 PM »

Hello Guys, I want to know C++ but Most the people said just learn C first then move to C++. Is it right if I learn C++ firstly I have complete C programming course? Anyone suggest to me. What the exact factor behind this?
Logged
fluffrabbit
Guest
« Reply #1 on: July 12, 2019, 12:24:16 AM »

Start with whichever one you like better. I started with C, couldn't quite do what I needed with 3D math, moved to C++, did that for a couple few years, then came back to C when I realized C is better. C is not necessarily more productive for games, but you tend to write better code in C.

C++ makes it very easy to write bad code. It adds a ton of syntactic sugar on top of C that can be convenient, but if used inconsistently it can make your code hard to read and buggy. If you plan on using an API that is or is built on top of OpenGL, DirectX, or Vulkan, you should use C++ because it has nicer matrix math libraries. If you are doing some kind of 2D game or using an API that doesn't require the big matrix math libraries, C is equivalent.
Logged
ThemsAllTook
Global Moderator
Level 10
******



View Profile WWW
« Reply #2 on: July 12, 2019, 07:00:33 AM »

Although similar, they're two separate languages. C++ is not a superset of C, and has different idiomatic usage patterns. C is a tiny language that can be fully learned in a weekend, while C++ is often said to be so complex that pretty much no one understands it in its entirety.

Because C is so quick to learn, it's certainly not a bad idea to learn it first. Every programming language you learn makes understanding further ones easier. This book is the gold standard for beginners: https://www.amazon.com/Programming-Language-2nd-Brian-Kernighan/dp/0131103628/

Also, you never know - you might end up liking C better and continue using it instead of its cousin. That's what happened for me. There's a common dogmatic assumption that if you're writing anything C-like, that it must be C++ and only C++, but this is not in any way necessary. Other than the rare C++-only or Objective-C-only API that I have to interact with, I've been using only C for game development for the last 17 years or so. I fell in love with the language at first sight, and it's served me extremely well ever since.
Logged

fluffrabbit
Guest
« Reply #3 on: July 12, 2019, 07:18:43 AM »

I guess you can pass a matrix as POD. I've been using C++ so much that I forgot how capable C is. Beginners coming from languages like JavaScript will probably hate the lack of high-level strings and dynamic arrays though. That was me a few years ago, and it took a long time to overcome the psychological barriers regarding memory management and raw pointers. But once your brain works that way, no problem.
Logged
raigan
Level 4
****


View Profile
« Reply #4 on: July 12, 2019, 09:00:10 AM »

About dynamic arrays in C, there's an stb lib for that: https://github.com/nothings/stb
Logged
qMopey
Level 5
*****


View Profile WWW
« Reply #5 on: July 12, 2019, 12:15:59 PM »

Personally I learned C first and got quite comfortable with function pointers, and then learning C++ was really easy.

For example, once someone knows this kind of thing in C:

Code:
struct allocator_t
{
    void* (*alloc)(size_t sz, void* udata);
    void (*free)(void* ptr, void* udata);
    void* udata;
};

Then understanding how to translate this into C++ can make a lot of sense:

Code:
class Allocator
{
public:
    Allocator(void* udata) : m_udata(udata) { }
    virtual void* Alloc() = 0;
    virtual void Free(void* data) = 0;

private:
    void* m_udata;
};

The above example shows two ways of implementing run-time polymorphism. In a similar fashion, templates in C++ can be understood by the lack of compile-time polymorphism (C would rely on macros or opaque POD byte buffers, which is more or less no typing at all).

Also, C++ is a really huge language with honestly too many features. I work daily in C++ professionally, and I don't know and don't care to know all of the language. I just stick with a subset of C++ features that work well, and more or less don't care about the rest in any way.

So you don't *need* to learn much of C++. It's up to you on how much you want to learn, and what.
« Last Edit: July 12, 2019, 12:23:39 PM by qMopey » Logged
fluffrabbit
Guest
« Reply #6 on: July 12, 2019, 04:18:06 PM »

About dynamic arrays in C, there's an stb lib for that: https://github.com/nothings/stb


And I'm using it. But there is also a learning curve. You have to free your STB arrays when you're done with them. With std::vector you just push_back and forget about 'em, badda bing badda boom.

@qMopey: That class shit actually has the opposite effect on me; it makes me like C++ less. Coming from JavaScript, where everything is an Object(), classes remind one of Java, and boy oh boy is that language not fun. Structs work great. Is that struct syntax C11? In C99, which I am perfectly happy with, it would be:

Code:
typedef struct {
    void* (*alloc)(size_t sz, void* udata);
    void (*free)(void* ptr, void* udata);
    void* udata;
} allocator_t;
Logged
Daid
Level 3
***



View Profile
« Reply #7 on: July 13, 2019, 03:42:03 AM »

@qMopey: That class shit actually has the opposite effect on me; it makes me like C++ less. Coming from JavaScript, where everything is an Object(), classes remind one of Java, and boy oh boy is that language not fun. Structs work great. Is that struct syntax C11? In C99, which I am perfectly happy with, it would be:

Code:
typedef struct {
    void* (*alloc)(size_t sz, void* udata);
    void (*free)(void* ptr, void* udata);
    void* udata;
} allocator_t;
No, it wouldn't. The result is for the C++ and C versions are quite different. As your actual object contains only a single pointer to the VTable. Which is a big difference if you have a lot of objects, memory wise. (Even more when you work in an environment where ROM is much cheaper then RAM, as the VTable can live in ROM)
Code:
typedef struct {
    void* (*alloc)(size_t sz, void* udata);
    void (*free)(void* ptr, void* udata);
} allocator_vtable;

typedef struct {
    allocator_vtable* vtable;
    void* udata;
} allocator_t;



On the original question, learn any other language first. C or C++ are both complex, hard to learn languages. Where if you make mistakes, it's sometimes really difficult to track down the cause.
C++ provides you with more advanced tools, but also more options to make mistakes. That's generally why people say start with C.

However, I say, start with any other languages, and learn proper, !simple! OOP principles first.
Logged

Software engineer by trade. Game development by hobby.
The Tribute Of Legends Devlog Co-op zelda.
EmptyEpsilon Free Co-op multiplayer spaceship simulator
fluffrabbit
Guest
« Reply #8 on: July 13, 2019, 04:20:16 AM »

I assumed OP already knows at least one programming language, possibly even a C-like language such as JavaScript. If not, hell, why not start with C? There was a time when that was the first or second language anybody learned, possibly after BASIC.


I had to look up VTables, because my knowledge of memory and data structures has gaping holes from all those years of JavaScript. I already "know" C, but I probably need to learn it as much as OP. I'm attempting to reverse-engineer what this does.

allocator_t uses allocator_vtable in a way that could be compared to class inheritance. All the asterisks mean that there are multiple layers of pointers, which is not a programming construct I'm used to.

Code:
void* (*alloc)(size_t sz, void* udata);

Void pointer, so it could be anything, but the style here resembles a function. Something called alloc is named. It looks like alloc may be a reference to an allocator function. alloc is dereferenced, which in this case does something that I do not know.
Logged
Prinsessa
Level 10
*****


Ava Skoog


View Profile WWW
« Reply #9 on: July 13, 2019, 04:50:38 AM »

It's a declaration of a function pointer to a function returning void *! c:
Logged

fluffrabbit
Guest
« Reply #10 on: July 13, 2019, 05:42:42 AM »

It's a declaration of a function pointer to a function returning void *! c:

That makes sense! I'm assuming that declaring the function in the struct is for the purpose of dot syntax to treat it as a member function. I'm not quite at that level yet, but I'm learning.

Let's say you instance allocator_vtable, ignoring allocator_t for now. The star at the beginning of alloc and free means it's a pointer, so you would have to access it as (*MyVtable.alloc)( size, (void*)&data ). When you wrap it in allocator_t, it becomes (*(*MyAllocator.MyVtable).alloc)( size, (void*)&data ). That syntax is so ugly that I'm sure I got it wrong.
Logged
Prinsessa
Level 10
*****


Ava Skoog


View Profile WWW
« Reply #11 on: July 13, 2019, 06:42:12 AM »

The arrow -> is syntactic sugar that allows you to turn (*a).b into a->b, and to run a function pointed to by a function pointer no dereferencing is necessary, so you can just do allocator.vtable->alloc().
Logged

fluffrabbit
Guest
« Reply #12 on: July 13, 2019, 07:14:23 AM »

C99 does not have the -> syntax.

So I guess it would be (*MyAllocator.vtable).alloc( size, (void*)&data ) though I'm still pretty hazy on the syntax of member functions in C. It's not an array of allocs (alloc*), it looks more like a dereference (*alloc), but declared in a struct. I suppose MyType (*MyFunction)(my_parameters) is the standard way of doing it. Funny we don't see a lot of C libs with member functions.
Logged
Prinsessa
Level 10
*****


Ava Skoog


View Profile WWW
« Reply #13 on: July 13, 2019, 07:27:44 AM »

Oh, I did not know that. o-o
Logged

Daid
Level 3
***



View Profile
« Reply #14 on: July 13, 2019, 10:41:03 AM »

C99 does not have the -> syntax.
It has... pretty sure it's older then C99, wouldn't be surprised if -> is part of the original C standard.
Logged

Software engineer by trade. Game development by hobby.
The Tribute Of Legends Devlog Co-op zelda.
EmptyEpsilon Free Co-op multiplayer spaceship simulator
fluffrabbit
Guest
« Reply #15 on: July 13, 2019, 03:44:10 PM »

 Facepalm It compiles as valid C89.
Logged
Renold25
Level 0
*


View Profile
« Reply #16 on: July 15, 2019, 11:42:09 PM »

Yes.  I am Also want to know.
Logged
kason.xiv
Level 0
**


View Profile
« Reply #17 on: July 16, 2019, 02:15:33 PM »

I would advocate for starting with C. If you're just starting with these languages it will be quite a while before you can recognize "proper"ly written C and "proper"ly written C++.

Until that point comes, C++ will seem like nothing more than a superset of C - and that's why I'd suggest starting there. No need to get overwhelmed with the infinite complexities of C++ before you have a grasp on how to write even the most basic things in C.
Logged
InfiniteStateMachine
Level 10
*****



View Profile WWW
« Reply #18 on: July 16, 2019, 06:27:22 PM »

I learned c++ first. It's hard to tell what changes when I was first learning would have benefit me most but I think I can say with some level of confidence that you should (edit)NOT learn to program with c++ as a starting language.

Do you already know how to program or is this your first programming language?
« Last Edit: July 18, 2019, 05:36:50 PM by InfiniteStateMachine » Logged

Endurion
Level 2
**



View Profile WWW
« Reply #19 on: July 16, 2019, 08:59:23 PM »

Take a look at C, but don't go too deep. If you ever thing using any of the strxxx functions or char*s as strings, you've gone too far.
Logged
Pages: [1] 2
Print
Jump to:  

Theme orange-lt created by panic