I know C++

I know C++
How hard is it for me to learn C

Attached: CPP.jpg (1280x600, 110K)

Other urls found in this thread:

dpaste.com/3DJHZA6
en.cppreference.com/w/c/memory/realloc
mail-archive.com/[email protected]/msg04823.html
twitter.com/SFWRedditGifs

just decrement

Takes 0 seconds cause you "already" learnt it
Actually just skimp through C K&R to be sure

Yet I see people on here complain about C/C++

Personally, I agree
It's not the same language but it's like German and Dutch
Very similar

What are the actual differences? Like you can not cast to a void pointer or something in C? Otherwise it's C++ without classes.

They're really two different languages and, if you're using the most modern standards of each, you're actually going to run into a lot incompatibilities. That said, if you know C++, C11 probably won't be too tricky to learn; if you're just trying to learn ANSI C, it'll be a walk in the park. The opposite (from C, particularly old C, to C++) is an entirely different story.

I've only taken C++ but my professor told me everything we learned was C
which is funny because I've accidentally saved files in C and try to write C++

Didn't work

>ANSI C,
I downloaded the second edition C book from the BSD guys
Seems like what I learned more or less

C is arguably easier than C++, C++ is so caught up in trying to *not* be C these days that C is the better choice IMO.

Why do you think that is?

Why I think C is easier than C++ or why I think C++ is more complicated than C despite the goal being to be a more intuitive language?

Syntax aside, you can understand how to write decent software in C usually in a few days. The standard library is relatively small and there aren't really that many edge cases for doing basic tasks. You can write C without having to have a webpage open for reference the entire time. If you want to write C++, or at least C++ that is considered "good" by the community, you better have cppreference by your side at all times because STL is fucking thiccccccc. Plus I think working with C code is more consistent anyway because there's far less disagreement on what's considered "good C" as opposed to what's considered "good C++", since there's so many different ways to use it

C++ has classes, templates, a significantly more robust set of libraries, additional memory management, type management and inference, a compiler that acts more like a colleague than a dumb text translator.

C and C++ and syntactically similar, but getting the most out of each really require different mindsets. A lot of people who prefer C actually like the limitations and constraints of the language as it forces them to think more about how to solve the problems they're trying to code. I like modern C++ for what it has become, but hell if all the major tech players don't shit all over it despite being a capable language.

Attached: 1420177771641.gif (500x334, 982K)

Some C++ things are nice, vectors and strings are nice, also objects are kind of nice. Much of C++ is a bit overcomplicated though.

std::vector and std::string can easily be replicated in C

I didn't know that. How does it work? For example a vector has dynamic memory and it deletes it, when it goes out of scope, how is that achieved in C?

it wouldn't when it goes out of scope, you'd still have to have a function to do that. the point though is that you can still get the same general functionality in C. here's a kinda barebones implementation i cobbled together: dpaste.com/3DJHZA6

everything in it gets freed when you call vec_destroy() once you're done. if you're deleting something in the vector before this you'd use vec_delete() which destroys the content at the specified index, and everything else is handled by realloc(), more info on that here: en.cppreference.com/w/c/memory/realloc

>For example a vector has dynamic memory and it deletes it, when it goes out of scope
dynamically allocated memory is not freed for you in C nor C++, it's just that in C++ std::vector's destructor (which *does* free all the memory, similar to my vec_destroy() function) gets called at the end of scope. since C doesn't have constructors or destructors, functions are as far as you're going to get

>dynamically allocated memory is not freed for you in C nor C++, it's just that in C++ std::vector's destructor (which *does* free all the memory, similar to my vec_destroy() function) gets called at the end of scope. since C doesn't have constructors or destructors, functions are as far as you're going to get

Yes I know. It isn't automatically freed in every case, it just so happens that there are some classes, that use dynamic memory and delete it in their destructors, like vectors or smart pointers. But I guess my post wasn't very clear.

Practically the same thing in syntax

learning c? easy. unlearning c++? harder.

wise words

Very, C++ and RAII largely make you incompetent at C.

You guys like Pain?
You guys think C/C++ is annoying ?

Try this Beauty
VHDL

>I know how C++
>Only knows how to say hello world in C++
>laughingwhores.jpg

No you don't.

That's not true
I can also follow along in tutorial videos and read stackoverflow pages

VHDL is shit, but Verilog is comfy.

I learned C++ before I learned C, and I now write C firmware for ARM M0 embedded systems. For me, the biggest challenge was learning to not do stuff like you do it in C++. Don't treat C libraries like you treat libraries in C++. Put your shit where it makes the most sense, not everything has to be "thing_1.h thing_1.c thing_2.h thing_2.c." When you do that, you gimp the entire language.

Get comfy with function pointers and allocating things to the heap. Put together, these can be used to create de facto function vector tables, which can be super powerful in the right hands.

If you want some fun libraries that are pretty easy to work with, libcurl and stb are both pretty fucking cool. stb (not to be confused with sbt) is braindead easy to use and there's a lot of cool shit in there.

If you haven't already, get comfortable using CMake or Autotools, or get yourself an IDE that takes care of the makefiles for you. Otherwise, you'll find yourself spending as much time fiddling with your makefiles as you spend actually writing code.

Also, always wrap your shit in this thing:

#ifdef __cplusplus
extern "C" {
#endif

//put your function declarations here

#ifdef __cplusplus
}
#endif


It'll probably never do anything of value for you, but it'll keep C++ folks from throwing a fit.

Attached: dak9CQz.gif (431x242, 232K)

I started with Cpp and went down to C. It doesn't take much. Truth be told is that you should really just combine C and C++ features that you like in your code.

>combine C and C++ features that you like in your code.
This sounds like a horrible idea

That’s because it is a fucking terrible idea.
Try using c-style strings that need a null terminator
Only a fucking idiot would want that instead of std::string

Std:strings are cool, but the real power lies in std:promise

I went from ANSI C to C++11 in like 1 month for my job. It was pretty easy. I felt like I was just learning an extended way to program structs.

You've just gotta get gud with malloc(), calloc(), and free(). Like I touched on here , in the right hands, granular heap management is the most powerful tool C has to offer.

I did my time in VHDL hell. Hearing the word "Xilinx" gives me flashbacks.

You are aware that there's other differences, right?

Attached: 1397342826270.jpg (800x800, 144K)

>Put your shit where it makes the most sense, not everything has to be "thing_1.h thing_1.c thing_2.h thing_2.c."

care to elaborate on this? i'm kinda interested in what you mean. in a lot of C codebases i read i see that there are more source files than headers, whereas in C++ i see more headers than source files. how do you normally structure everything?

Sepples programmers have a tendency to make one-off header only libraries with full implementations in them, because otherwise they end up doing dumb shit like having to implement static clases.

C programmers basically do the opposite since most files dont really need to know about each other in the same scoped way, so you just skip the header and put your declarations at the top of the C file

>granular heap management is the most powerful tool C has to offer.
malloc and free isn't granular

Both of these practices sound like bad code organization.

Not same fag, but it's arguably more granular than python...

The latter is better than the former. If nothing else needs to know about the functions in a file, skip a header and just write the c file.
Cpp takes the opposite approach, where you have something needed but not worth building an entire class for, so you write an extra header only library and include it somewhere to prevent class bloat. Plus it makes it portable.

Right, and for large programs the Python solution will probably make better use of memory and have less memory errors. Any significantly large C or C++ program is going to have multiple leaky garbage collectors with bad interfaces.

Same way it's done in c++ :)

It can vary wildly on a case-to-case basis, that's the great thing about it.

I actually have a decent example from one of the libraries I'm currently writing at work. Here's the context, because I feel like this doesn't make sense unless you have an idea for what the code is doing:

I'm using an array of structs with function pointers to break out a single MCU interrupt service routine into an arbitrary number of user-defined functions which the user can tailor to their exact needs. This structure also means that each component of the interrupt routine can be enabled/disabled during runtime without affecting the rest of the interrupt, with no fucky syntax or globals required (interrupt routines take no arguments and exist only in the global scope, so any values that need to be kept from an interrupt routine typically have to be stored globally. My solution creates a workaround by using the interrupt as a dispatcher for the user's functions, which allows me to pass things into the user-defined pseudo-interrupts).

Here's the part that's relevant to the header/implementation files:

The user defines each struct that goes into the array in one .c file, and the functions contained by those structs are defined in a different .c file, but the declarations for both the structs and the functions declared by the structs go in the same .h file. Since the structs are gonna be kind of a "define them and never touch them again" thing, but the functions are much more likely to be tweaked during the development process, it means the library's user doesn't have to sift through a bunch of structs to get to what they're actually looking for.

Attached: 1527721159074.jpg (1000x1000, 128K)

>vector
Allocate on the stack.
>string
char*
>objects
Struct.

I like you user, but for all the C++ folks: please don't use structs like classes. There's a lot of things a class can do that a struct can't, and vice versa. Take advantage of what structs are capable of instead of trying to awkwardly warp them into something they aren't.

The shit I do is typically ~30,000+ lines of C code per project and we never release leaky code. It's not just a pride thing, we can't: if the heap suddenly takes up more space than it's allowed to, the MCU will perform a hard reset (ex: PIC24 and PIC32) or it'll just freeze (ex: most ARM Cortex, as far as I know), and unexpected resets/freezes could have disastrous consequences in application.

I guess, hypothetically, you could make a garbage collector for an MCU, but the GC itself would have to be airtight in order for it to be useful, so you might as well just do the original code right in the first place, instead of making a thing that just cleans up fixable mistakes and wastes precious time and program memory. Garbage collectors are fine for devices that have a couple threads to play with, and are fast enough that spending a few clocks on something that isn't pertinent to the application itself. Generally speaking, embedded systems have neither of those luxuries.

Attached: 4fe7dbb.jpg (500x1200, 65K)

very. C is just utter shit in comparison to the sane runtime and abstractions C++17 offers. I mean. really. why downgrade?

>I guess, hypothetically, you could make a garbage collector for an MCU, but the GC itself would have to be airtight in order for it to be useful, so you might as well just do the original code right in the first place, instead of making a thing that just cleans up fixable mistakes and wastes precious time and program memory.
The symbolics 3600 had hardware support for GC and dynamic type checking, IIRC.

>Garbage collectors are fine for devices that have a couple threads to play with, and are fast enough that spending a few clocks on something that isn't pertinent to the application itself. Generally speaking, embedded systems have neither of those luxuries.
Fair enough. Although, systems like mail-archive.com/[email protected]/msg04823.html exist.

>symbolics 3600
That's some old school shit, but that's fascinating! Now I kinda wonder if any modern architectures have tried something like this, though I guess in this day and age it could potentially be abused by malware.

>systems like...
I've heard of this, and my employer does something sort of similar with some of our products (just a proprietary Pascal-like lang instead of a Lisp dialect) but picolisp is still pretty heavy relative to bare-metal C. That weight isn't a big deal if you're talking about something like a Cortex-M7 that can run at upwards of 400MHz, but if all you've got is a 48MHz M0, picolisp can weigh you down.

Attached: 1412890238464.png (679x662, 255K)

through a lot of hand waving of the useful features of C++ and ignoring their existence, then pointing you towards a whole lot of extra work for no good reason other than "C"

Why learn C? Just read docs if you ever need to use it

I’m very interested in learning C++. I’m familiar at an intermediate level, but I’m wondering what the benefits are of learning it.

C++ has no useful features if youre not retarded.

I'm not sure if I was clear enough about my second point. The picolisp system is in Verilog. It is the chip. Of course, getting it manufactured might not be easy. What exactly did your employer do with the Pascal system? Implement a p-code interpreter for a MCU?

literally every difference:
declaring a struct variable requires the keyword
no classes
no default parameters for functions
no pass by reference using the & operator, pointers are used instead

I use C++ at work for who knows how many years.

What I found when teaching newbies (that don’t know C) is to teach them pointers last. I put focus on , RAII, containers, vocabulary types, std::future etc.

The problem arise with develoers that have C bacground. Oh boy. They new/malloc’d absolutely everything creating so many leaks because of course they forgot that delete operator. They for some reason put all stack objects on top of a function even though I heard you don’t have to do it anymore i C creating slowdowns. They insist on using low level threads library causing deadlocks left and right.

It’s a challenge.

...

It depends on what kind of C++ you know

>I know C++
No, you don't.

>using low level threads library
What's the better alternative? Still new.

You can use c++11's threads instead of using a library provided by your os.

user you use high level tools. Like std::async and std::future for bacground tasks. For calcuations use paraller algorithms. For more complex tasks

Avoid using std::thread unless you are library writer and absolutely know what you are doing.

about as long as it takes you to UN-learn the parts which were added to turn it into C++.

Attached: download_20180627_235938(1).jpg (450x286, 71K)

Kek