Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
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 Cool) 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?
_iPhoenix_ wrote:
If it doesn't have pointers, structs, or dynamic memory allocation, it is practically useless.

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.
PT_ wrote:

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've never had a problem with this so I can't feel your pain Razz 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.
PT_ wrote:
_iPhoenix_ wrote:
If it doesn't have pointers, structs, or dynamic memory allocation, it is practically useless.

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.

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.
c4ooo wrote:

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.
PT_ wrote:
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 obviously haven't been introduced to C unions yet Wink


Code:
typedef union {
    uint8_t *ptr;
    uint24_t val;
} my_t;


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 Wink
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.
Tari wrote:
c4ooo wrote:

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.

Didn't notice the that one was a pointer Wink
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")
PT_ wrote:
It gives an error if you mess up uint8_t* and uint24_t, while they are almost the same.

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

PT_ wrote:
What is the difference between char* and uint8_t*?

One is signed the other is not
Lionel Debroux wrote:
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.


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 Smile

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.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are GMT - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement