I have been learning C (for the computer, but I'm pretty sure this applies to the CE version, too) and I find it amazing.

I grasped the basics easily, thanks to amazing documentation and resources that can be found easily online.
My 'IDE' (Sublime Text and Terminal ) is easy to use, well organized, and simple.
The syntax is very clear, quick, and concise. (At least where I'm at, but that code to initialize a window looks scary as heck)
The syntax is also very similar to other programming languages that I know, which is a plus.
The language is INSANELY fast, it makes freaking Java look like a tortoise (which makes sense)
It doesn't make my mac freaking explode when I try to run a program (long story, but let's just say that I melted some things with a Java program by accident that should basically never melt, or be affected by my lousy programming)

In honor of this programming language, I have upped my standards:
If it doesn't have pointers, structs, or dynamic memory allocation, it is practically useless.
Ok, that's somewhat exaggerated, but it gets the point across

I've been meaning to learn C so I can use the CE libraries, but I don't know where to start. Any suggestions?

So ICE is useless.
Anyway, I admit it is a great language, it's rather easy to learn, and writing code goes fast. However, the BIG thing I don't like is all the different variable types and the fact that you need to define everything. It gives an error if you mess up uint8_t* and uint24_t, while they are almost the same. What is the difference between char* and uint8_t*? You need to define every function, with it's exact arguments and return type. If you are not used to that, like me, it is pretty hard to understand.

I have a strong taste for C, especially its characteristics that make it the ideal "portable assembler." However, it introduces some bad habits that you'll have to undo later when you get into higher-level programming, like void pointers.

As for char and uint8_t, just use the char type to represent a character; do not attempt to use it to represent a number. Use int when the bit width is not important at all for your number (you just want an integer between 16 bits and 32 bits), uint8_t when you just want an 8-bit register, or int_fast8_t when you want the fastest register available by the target architecture that has at least 8 bits (make it uint if you do not expect negatives).

I'd go with int_fast8_t for small math. I'd also go with smearing const all over your code to maximize compiler optimization (not that that kind of optimization is really possible, as it's not clear how well Zilog wrote their own compiler).

I don't trust long int or long long int, as they can be exactly the same width by standard.

I've never had a problem with this so I can't feel your pain Also a char is not guaranteed to be 8 bits(neither are many other C primitive types; they vary from system to system), the entire reason the intX_t types exist is to give exact variable sizes so please don't use char instead.

So more control and optimization is a negate aspect ???
The difference between uint8_t* and uint24_t is that one is 8 bit and one is 24. If you don't know if your number will be 8 bit or 24 bit then just use the higher one.

Patently false. One is a pointer, the other is an integer. C makes no guarantees about the machine representation of either category of values, so they're incompatible. In practice most (but not all!) machines use compatible representations for pointers and integers, but they still behave differently with various operations. Obvious example: it doesn't make sense to multiply a pointer, and same operator is recycled for deref.

You obviously haven't been introduced to C unions yet


Code:


The difference between a char* and a uint8_t* is that one points to signed implementation-defined data and the other to 8 bit unsigned clearly

Using a C++ compiler to program in a C-like way brings stricter type checking, and other goodies, not limited to syntactic sugar. This is especially valid when using C++11 and newer revisions of the language, which are fortunately becoming the default nowadays.
When I want to make a quick C-like test program, I now usually write C-like C++14 / C++17 (I request those standard versions from the compiler, even if I barely use their features, of course).

If you're looking for safer, higher-level, productive yet fast languages, Go has become a relatively obvious choice.
If you're looking for safer, low-level languages, Rust has become a reasonable choice - but there's a much steeper learning curve.

Didn't notice the that one was a pointer

C is just great. I prefer it over most languages for almost everything.

Some side affects for me from learning it though... I now find it impossible to use scratch. I don't know what it is, but I just can't put up with it.

I've always hated scratch, because:

a) I can't do **** in it. (i.e. Not versatile)
b) Flash sucks
c) It's a little too high level for my current tastes, and
d) It taught me bad programming habits.

It does have some benefits:

a) easy to teach to relative youngsters
b) easy to understand, and
c) helpful community (screw you, Java forums from when I was learning it, there's a reason I came to the site, and it wasn't to get a "well, here's the code" or "you noob")

While a uint8 pointer may basically be a uint24, you do not really want to be confusing pointers with ints, assigning one to the other etc


One is signed the other is not

Despite what the marketing has said, Go occupies an entirely different niche than C. I've found Julia to be a much better (and faster!) alternative in that niche as well, unless you need constrained memory use and guarantees.

Although I know nothing about them, I find Go and Julia naturally unrepetitive due to their names alone.
I would rather be programming in something called 'C'

Does that make sense to anyone?

Yeah, vaguely.

Indeed, Go isn't in the same niche as C. I tried to capture that in my previous message by "higher-level", which was probably too terse

But, er, Julia ? Articles such as https://danluu.com/julialang/ , from a competent and usually level-headed person (taking suggestions from e.g. Julia "b0rk" Evans, also usually known as a nice person, into account), don't give me much confidence in it, whether for the language itself, in terms of stability and reliability, or the toxic maintainership and community around it...
That article isn't overly old and outdated, given that he wrote it some time after stopping bothering with Julia in October 2014, and "Update 2, 1 year later" brings us into 2016.

The fact that most of the container ecosystem is based on Go, and Go is spreading elsewhere, isn't just because of marketing. At work, over the past ~5y9m, I've worked on two main projects, and if they had been started in 2016 or later, by the same persons with the same sets of skills, I'd have strongly pushed for a close examination of Go, rather than respectively C++11 and Node.js + later Java. Chances are that the development process of the former project would have been faster, and the latter project wouldn't be such a slow and unmaintainable mess.

Lionel, I see C as having three main use cases today.
1) Low level systems programming implementing the higher level functionality other languages use. No one designs languages with this in mind because C has won it so thoroughly.

2) Embedded systems. C's dominance in the embedded sphere is really only challenged by C++ and potentially Rust in the future.

3) HPC. C and fortan are the unrivalled kings, but Julia and Python/Numpy+Pandas fit this niche amazingly well. Golang designers made some shockingly poor internal choices that really limit its applicability.

The whole design philosophy behind Go is to eliminate the dangerous freedom that makes C so suited for these. I don't see it ever being a good alternative anywhere C would be acceptable to use.

Yes learn C and learn more programming languages in addition to it.

You see, I started with C. I would write scripts to that would normally be programmed using Bash or Python using C and it would take longer to write those scripts. Also I would only run them a few times so the additional time spent writing that program was not worth it.

A hammer is great for nails but it cannot be used for everything.

I've always wanted to properly learn a low-level programming language - C is definietly on the list. There's a lot of really great use cases I can forsee with C but unfortunately, don't have the time rn to pick it up.

edit: sorry I've just now realised these are archived posts, my bad