C programming thread

I'm relatively new to C and I love it.

Any tips or challenges?

Other urls found in this thread:

youtube.com/watch?v=KlPC3O1DVcg
2016-aalto-c.mooc.fi/en/Module_1/index.html
raw.githubusercontent.com/gatesphere/demi-16/master/docs/dcpu-specs/dcpu-1-7.txt
tldp.org/HOWTO/Module-HOWTO/
twitter.com/SFWRedditVideos

>any tips
Make sure you know how to use debugging tools like gdb and valgrind

I have gdb but have no idea how to use it, guess I look up something

>Any tips
Don't fall for the C89 meme. Always use the latest standard.

Yeah, I got that covered

Hey, bit like OP here, I've got some decent experience down with Python and C# and I'd like to get started learning C, any advice?

Save yourselves a lot of pain and suffering, and just use c++. Why would you want to go out of your way to make your life harder, when c++ adds functionality that makes your life easier? Especially when its backwards compatible with c functions. For example, parsing dynamically allocated c strings, the fucking bane of my existance, is rendered almost trivial in c++. malloc(arraySize * sizeof(char*));? Fuck that shit, c++ let's you just use 'new.'

Can C++ be used as close to the metal as C can?

C++ is a horrible clusterfuck of a language. C does C's job a lot better than C++ ever will.
>adds functionality that makes your life easier
That is one of C++'s problems: too much shit. There are umpteenth ways to do something, so it leads to programmers subsetting the language. One person's C++ is completely different from another person's C++.
>Especially when its backwards compatible with c functions
Another advantage of C. It has a very simple ABI, so practically any other language can call its functions. That is why C is the language of choice for libraries.
Also, in terms of language features, there are many features that C has but C++ doesn't. It is in no way a superset of C.
>malloc(arraySize * sizeof(char*));? Fuck that shit
You just suck.

>backwards compatible
Not that you'd want to, but you could literally write pure c as a c++ program. So, I'd say yes. It can do everything c can, and more. Hince the ++.

NEVER use GCC

Why not?

It's not 1980 anymore. C has evolved since then.
Here is a little test.
In C++, create a static int array of 10000 elements, where they are all zero, and the 10000th element is 1, without using any initialisation code.
Here is the C solution.
static int array[10000] = {
[9999] = 1,
};

After using C++ instead. C is a total meme.

Start*

You're not understanding. I could take the code you just wrote and embed it in a c++ program and it would work just the same. C++ is C, you can use it just like C, but it also has more things that make what was a pain in C easier. But only if you want to use them.

>I could take the code you just wrote and embed it in a c++ program and it would work just the same
No you can't. It's literally a feature that C has but C++ doesn't.
It MAY be supported as a compiler extension, but I don't know.

How about something more useful?
How do I make a guarantee that two pointers in C++ don't alias?

It's going to be quite a bit different from what you are accustomed to. It's a small, terse language, in which you have complete control over your machine, or in most cases, as much control as the OS will allow you to have. My advice is to think of a project that you'd consider C worthy, and is something you think you could write in a week or so. Then, find yourself some time, and work on it. If you continually find yourself saying "this feels like a step backwards" than you are using C for the wrong application.

Idk I guess just check if the value of pointerA == pointerB? I mean, how would you do it in c?

I had function arguments more in mind.
Anyway, I was pointing out the fact the meme++ doesn't even have restrict pointers.
void my_fn(int *restrict a, int *restrict b)
{
/* a and b don't alias.
* The compiler can now make much better optimisations
* knowing that
*/
}

Actually, upon a little further investigation, it seems that g++, and many other c++ compilers, support __restrict__. Which does the same thing as its C99 counterpart.

>C++ is C, you can use it just like C
There are a few things that are valid in C but not in C++ (don't remember anymore but it was something about void pointers).

Non-standard shit.

command line arguments are nice

Who cares? There's nothing wrong with using something outside of the standard if its useful. There are only a few scenarios where you're required to stay strictly withing the standard and use functionality only c has, and in those situations, sure maybe C would be a slightly more advantageous choice. But in most general cases, it's just more trouble than it's worth. I mean, you could apply the same logic to writing all code in assembly. Why don't we just do that for circuit level control? Because there are better things that make programming easier and more intuitive. Same with C++.

Please don't listen to this guy. C++ is shitloads more difficult to parse than C and will effectively lock you in to a specific toolchain if you do decide to use it. If you want to work with other code that is written in C++, please be my guest, but there are far better approaches to OOP in other languages is that's what you are after.

If you allow non-standard shit to be judged as part of a language, then the whole concept of comparing lagnguages breaks down.
I could extend C, C++ or ANY language in any way I want (which doesn't affect conforming programs) and say that it is better than anything.

What did he mean by this?

youtube.com/watch?v=KlPC3O1DVcg

I'm taking this course, currently on chapter 3 and stuck on link lists..

2016-aalto-c.mooc.fi/en/Module_1/index.html

Is K&R a meme for learning C as far as being outdates?

No, not really. Treat it more like the C documentation or reference manual than an educational textbook though. If C is your first programming language than you're going to want to supplement your learning with a book that's more newfag friendly, but if you already have experience in a language like C++ then K&R should serve you fine.

IMHO it's the best start.

Just don't try to apply every funky stuff you see there. You can do a lot of "dirty hacks" in C, but that doesn't mean you should.

>you could literally write pure c as a c++ program

Utterly wrong.

As long as you avoid virtual functions, exceptions, and other shitty bloat, and you just use it as "C with classes", AND you are working on a project that benefits from an object-oriented approach (game engine is one I can immediately think of) then C++ is the better choice.

I thought it was just a reference manual at first and tried a "real, educational textbook" like Head First C
made it into like the third chapter writing stupid number guessing games before I wanted to kill myself from boredom

If you turn off your computer, open up a paper notebook, and get some coffee, K&R is far more useful. Covers entire chapters of "learn programming!!" books in a couple of pages.

>game engine is one I can immediately think of
Game engines do NOT benefit from OOP. In fact, OOP's terrible performance hurts it.
>As long as you avoid X, Y, Z
Exactly as I said, it leads to shitloads of subsets of C++.

>Any tips or challenges?
Graduate middle school, abandon C, and code something useful with Javascript or HTML.

At least put some effort into your bait.

The truly redpilled approach: high-level language with excellent FFI support for C, like Chicken Scheme.

But OOP is just a different way for a programmer to "visualize" and manage code. It is still more or less the same binary that C would produce, although admittedly with a bit of bloat added in support of certain C++ features.

Using C++ like that does create subsets, which genuinely sucks and is a big problem for open source projects with public contribution, but in a proprietary industry setting you just hand new employees a reference guide for your company's/team's subset and call it a day.

>It is still more or less the same binary that C would produce
No it won't. Compilers are filled with magic and fairy dust that will optimise your program into the most efficient program possible.
OOP has huge issues with cache locality, because you're spreading all of your information over several objects.

Yes and no. It is possible but on low mem devices objects are hell to maintain

no, k&r teaches proper C style.

Fuck, I've made 5 separate attempts at learning this shit, the Head First C book is just sitting there on my desk now

I feel like I'm just tossing code into a void going through video tutorials and that book I got is barely helpful since it assumes that I know Java for some fucking reason.
Is there a list beginner projects I can work on (preferably with ramping difficulty)? If I know one thing it's that I learn better by applying and figuring things out as I go

>Hello world
>Fizzbuzz
>Knight's tour
>Prove P = NP

DCPU-16 emulator.

raw.githubusercontent.com/gatesphere/demi-16/master/docs/dcpu-specs/dcpu-1-7.txt

it's pretty hard when most of the good books about C are still in C89

It's honestly my favourite textbook. Concise but still very educational. Great exercises. My only issue with it is that it assumes you know some stuff about how computers work on a low level (only basic shit like twos complement)

C doesn't guarantee that integers use twos complement. I don't think K&R would have made that assumption.
It's been quite a long time since I've read it though, so I might be wrong.

RMS has a good tutorial for it.

I'm not the user who suggested it, but I can't agree enough that gdb is important for learning C. Also, when you're using it, run tui enable

That'll make your life much easier.

There are some exercises like 'Explain why the above doesn't work for 128 on an 8 bit twos-complement machine'

I prefer ddd over TUI tbqh.

Write a device driver for a printer or webcam. By the time you're done you'll have a firm grasp on both C and hardware level programming

Thinking about it, that's actually a really good question. It's important that people understand that you cannot always take the absolute value of the most negative number.
But I do see your point. However, I don't think K&R was ever indented as a beginner's book. It clearly expects you to know a little bit about programming before going in. Even high-level languages expect you to know about twos complement.

Its hilarious to me after being a developer for over 25 years, people are still having the exact same arguments :D

hello grandpa

>:D
How could you have been a developer for 25 years when you're clearly a 15 year old?

>learning programming from books
Doing it wrong, you should only read K&R to get the basics. After that, you should study real code and make your own projects.

I'm interested in learning to interface simple hardware, like webcams or lcd displays. how should i approach this? Just looking at the datasheet is confusing me.

Start with something simple like reading and writing to pins on a parallel port. You can pin out directly into a LED and make the LED turn on and off.

It's relatively easy on Windows, but even more so on Linux.

tldp.org/HOWTO/Module-HOWTO/

new is the past,now you have smart pointers

>unironically using meme pointers

>smart pointers are a meme
That's it, I'm leaving Sup Forums forever. Sup Forums can't program for shit.

>dude, do you know what would make this fast memory access operator cool?
>make it an object for all those extra cache misses


>DUUUUDE

>cache miss
You obviously don't know how smart pointers work.

Smart pointers (lets stick to shared_ptr here to keep it simple) are basically just a reference counter, that increases on entering scope and decreases on leaving scope.

When dereferencing the pointer, there are no additional steps other than some encapsulation code that the compiler will inline and optimise away.

nice try bjarne

enjoy your bloated, huge "superset" of C

I'm reading it right now. It's not a beginner's book in that it doesn't introduce basic concepts from CS and whatnot, the book assumes you know a lot of shit and I like it for that. You will learn C and you will like it.

He says C is obsolete because he thinks C and C++ should've merged into a single language. In his view, C++ does everything C can do, but the "plus plus" in C++ helps with working at a higher level of abstraction, which makes doing more complex things easier (as he explained with his example about matrices).

Maybe be more specific than just "this", since "this" could be any part of the video.

I think that whole "new" problem has been taken care of since c99. Also, you could just set up a single line preprocessor macro for a lot of the syntax based changes that you want to make for yourself.

I am not anywhere near C handy but C is thus far much more compelling to me both in performance and the "feel" of it as it runs in my machine. I have an ear problem so it's amazing to be able to get such a light runtime.

gdb isn't that complicated at all. There's 6 keywords and they're all pretty straight forward. Aside from that there are the flags and extensions to consider but if you've got a good grasp of your own program you really shouldn't need gdb to do more than run through small seg faults. Of course, that carries the assumption that you are coding based on the design implementation K&R and the rest have/had in place for it [C].

How do I compile and run a C program inside emacs without using M-x shell-session? Is there some other way?

For example, parsing dynamically allocated c strings, the fucking bane of my existance, is rendered almost trivial in c++.
malloc(arraySize * sizeof(char*));? Fuck that shit, c++ let's you just use 'new.'

>malloc(arraySize * sizeof(char*));
and exactly what's wrong with it? few data types is too much for you?

>where they are all zero
>without using any initialisation
>Any challenges?

write function that interweaves elements in multiple linked lists
so that i1->i2->i3-in ; j1->j2->j3-jn ; k1->k2->k3->kn
becomes
i1->j1->k1->i2->j2->k2->i3->j3->k3->in->jn->kn etc.

M-x gcc ..
M-x eshell ..

well M-x gcc doesn't work, but doing eshell and invoking gcc from there works.

M-c compile gcc ...

M-x

got it. Running the compiled program in eshell works.

C-c C-c
but you have to bind it to compile command.

what if your area of interest is embedded stuff

wasn't K&R mostly written for FORTRAN programmers?

Safely handle a string without rewriting the entire string library and maintain portability.

hint: you can't

learn how to write a makefile and do this

I have never once in my 10+ years programming C needed gdb or valgrind to debug a program.

That's just syntactic sugar. The core of the language hasn't changed. C is simply too old.

I'm actually thankful for that.
C libraries are always so easy to understand because they don't make use of things like namespaces.
In fact, they always work the same way.
Create a little context pointer and have black box functions do operations on the data in the pointer.

Doesn't matter.
You can't do this in c++.
int *x = malloc(sizeof(int));

Can confirm it's only a meme if you've never programmed before. But other than that it's god tier, so far the best quality over quantity tech book I've ever read. Short but extremely detailed and to the point. Picked up a used copy for $15, best I've spent in a long time.

That's no feature unique to C.

Too verbose.

But it doesn't relegate the minding of a data table to class distributions. That's literally a whole half to programming, managing memory so that the most important data is at the front. You can do that in c++ too but it'll be placing all data at the end if you use `new`. So instead of worrying about stuff like that, and how new hardware makes it negligible ( it doesn't ), you can use a macro in C and get the same effect you would with new except that now you also get to put the data at the front if you want without having to access the class before you can reach your desired function.

There's not much of a reason to use C11 over C99. Most of the appealing features of C11 were library features that don't have much support.

C++ has some features that make getting things to work a huge pain in the ass. That's why I try to use C when I can.

I don't know why people think you can't use C++ on embedded. It works fine if you don't do anything stupid, like bloat the code with thousands of template functions.

That's bad style. Do this instead:
int *x = malloc(sizeof(*x));


You can't fuck up if you do it this way.

There is no reason to NOT to use C11 over C99.
Both Clang and GCC support C11, and even default to them.
Sure, C11 doesn't add a huge amount to the language like C99 did, but there are several little things which make it nicer.

It's not valid c++

>There is no reason to NOT to use C11 over C99.
Compatibility. It can compile on older versions of GCC on older computers.

>using malloc at all in C++
I know I need to add a cast to int* on the return value of malloc. Is that all that makes it illegal in c++?

That's a stupid reason.
Why not write it in K&R C, so you can be compatible with the first version of GCC?
GCC 5.1, which was the first version to default to C11, was released over a year ago. You should expect most people to have at least that. Even then, earlier versions support C11, it's just not enabled by default.
Also, if you're going to limit yourself to the annoying and ridiculously slow release schedule of Red Had and Debian, you'll basically never get to use ANY new software.

No.

The original claim was that everything c is valid c++ which is not true.

Whatever, I don't like to use something new and shiny unless I absolutely have to do it and there's no other way to do it.

Do you still use CDE?