ソースを参照

About compilers, editors and distributions...

master
コミット
4e427825ac
2個のファイルの変更64行の追加3行の削除
  1. +17
    -2
      chapters/chapter_1.c
  2. +47
    -1
      xhartae.c

+ 17
- 2
chapters/chapter_1.c ファイルの表示

@@ -18,8 +18,7 @@ ASCII table looks like, I don't like encodings like UTF-8 and others, so neither

ASCII table:
_______________________________________________________________________________________________________________________________________________________________
| 0B | 0O | 0D | 0X | SYM | Full name | 0B | 0O | 0D | 0X | SYM | Full name |
|_______________________________________________________________________________|_______________________________________________________________________________|
|_0B______|_0O__|_0D__|_0X_|_SYM_|_Full_name____________________________________|_0B______|_0O__|_0D__|_0X_|_SYM_|_Full_name____________________________________|
| | |
| 0000000 | 000 | 0 | 00 | NUL | Null | 0000001 | 001 | 1 | 01 | SOH | Start of heading |
| 0000010 | 002 | 2 | 02 | STX | Start of text | 0000011 | 003 | 3 | 03 | ETX | End of text |
@@ -149,6 +148,22 @@ int character_is_hexadecimal (char character) { // Same as function 'character_i
return (character_compare_array (character, "0123456789ABCDEF"));
}

/*
Now, we can see how function 'character_compare_array' was implemented, but know that it could be even shorter, like you see below. However, I really think it's for the best to
use curly and round braces, when even the compiler won't warn about them. You can easily see the scope of something if you have a text editor capable of highlighting matching
braces, and almost all of them have that feature.

@C
int character_compare_array (char character, char * character_array) {
for (; * character_array != CHARACTER_NULL; ++character_array)
if (character == * character_array)
return (TRUE);

return (FALSE);
}
@
*/

int character_compare_array (char character, char * character_array) { // I didn't use name "string", but "character_array", to explicitly show the intention of argument.
int offset;



+ 47
- 1
xhartae.c ファイルの表示

@@ -29,12 +29,58 @@ Why should you learn or use C programming language in 2023?
- C can interface with huge variety of other distinct programming languages.
- C can be a lot more readable, faster and easier if used well.

Before we get into it, there are some requirements that this book is based on. Thou shalt use GNU/systemd/Linux operating system, commonly and wrongly refered to as Linux OS or
just simply distro (distribution). They come in many flavours, so if you're new to this, you could just install BunsenLabs, LXLE or Mint on some old laptop, if you don't want to
switch totally from spyware known as Windows (niche OS made for games). You'll revive your old laptop that was useless, and you support free software by doing so, making you a
part of the revolution. Beside that, you'll need a C compiler such as TCC, GCC (which is preinstalled on most distros) or Clang, and lastly Valgrind and Splint, to verify the
quality of your C source code. Text editor or IDE is a trivial thing at the begining, but it'll shape your coding style in the long run. Lets talk about them.

GNU/Linux operating systems:

- LXLE: Entire distro based on motto "Revive your old PC", so you understand everything. It's based on (L)Ubuntu and uses LX desktop environment. It comes preinstalled with a lot
of useful software, so you can work with it as soon as the installation is finished. If your old machine was struggling with XP, it'll fly with this.
- Mint: You can consider it as a noob Linux distro, but all that aside, it's good introduction to freedom, as it looks very similar to Windows, except nicer. I prefer to suggest
over Ubuntu for new users (revolutionists). You can also use it out of the box, since it comes with a lot of good software.
- BunsenLabs: Easy to use distribution, and I personal use it. I like to call it "hybrid distro", because it doesn't buy into big ideas like universal window manager, desktop
environment, or anything else. It just literally works, and you're free to modify it however you want, nothing breaks and it's friendly with older hardware.

C compiler and other tools (and other compilers...):

- TCC: Tiny C compiler, imagine that you just want to compile some huge program that's taking forever to compile (and it's not written in Pust "programming" language). Then just
compile it with TCC, it'll be around 10 times faster than GCC or Clang, but it'll do less optimizations and less error checking.
- GCC: GNU compiler collection (formerly known as GNU C compiler) is beast of a compiler, with decent optimizations and error checking, but it's very old and sometimes produces
errors that cause SIGILL (Illegal instruction) on Linux (on Intel's x86-64 CPUs). Also, it was rewritten in C++, so no wonder...
- Clang: LLVM C compiler, I personally dislike it, but don't mind my opinion too much. It has good warning messages, so sometimes I use it with flag '-Weverything' in order to see
that my code is absolutely correct. It also has quite good optimizations, but I couldn't care less about that honestly.
- Valgrind: Heavy metal program for checking memory leaks (when using heap memory / dynamic memory management), I absolutely love it and use it to test all my C programs. I use it
with '-g' flag passed to the compiler I'm using to use debug symbols in generated object files. Every single C programmer needs to use it.
- Splint: Careful with using this one, it's old and outdated C linter. It basically prints warnings about your C source code, without compiling it, it's called static code
analysis. In order to use it efficiently, you'll need to learn some flags, and we'll cover that in future chapters.
+ GNAT: GNU toolchain made for Ada programming language. We'll briefly talk about other older and newer programming languages in this book, Ada, Fortran, flat assembly mostly
positively, and C++, Rust, Java, mostly negatively. You don't need this, it's just an extra, in case that (Gott forbid) you want to learn more.
+ fasm: flat assembler, not a compiler, close to interpretter, but not quite, is the most unique piece of software I've ever seen. It's implemented in itself, which is something
you can do with C too, write your own C compiler, compile it with TCC, and then recompile it in itself. You will need assembly knowledge.

Text editors or IDEs (integrated development environments):

- ed: It's the STANDARD text editor for UNIX-based operating systems. Nothing else can be said, it's literally the best tool I've ever seen, and I use it sometimes.
- kilo: Terminal text editor, written in C language, less than 1000 lines of code. It's nice, simple and usable, and you can extend it once you learn C.
- nano: Also terminal text editor, very simple to use, but some prefer micro over it. You gotta admit, people are very creative when naming their software...
- Vim: Beast of an editor, once you learn how to exit it, you'll be like a Gott to other non-Vim users. I won't tell you how to exit it. I don't know.
- Emacs: Yet another beast of an editor, your pinky finger will be twice stronger because of it. It has many extensions and all PROs use it.
- Mousepad: State of the art text editor, it works same as Notepad, but it's more based. You really don't need anything more complex than this for editing a text file.
- Geany: I use it most of the time, but I switch to nano, Emacs, my own text editor whenever I feel like it, in order not to limit myself to just one tool.

Jokes aside, don't obesess over any distro (as long as it's some kind of Linux, BSD is cucked), any kind of compiler and any kind of text editor! You only want to edit text file,
insert and delete few lines of code, nothing more. You don't need some IDE (bloated text editor) that uses 2 GiB or RAM, opens up after 10s of blank window, and work slow overall.
Just don't use any of the following for reasons you'll understand once your grow up: Windows, MSVC, VS Code, Visual Studio, Atom, Helix, Kakoune, Eclipse, Sublime.

One sane C program should have the following structure (please keep in mind that this is a book, not a sane program, thanks...):

0) Optional file, author or license information in comment.
1) Header guards and implementation definitions.
2) System header files then project header files.
3) Macro definitions.
3) Macro definitions (please avoid them).
4) Internal function then variable declarations.
5) External function then variable declarations.
6) Internal function then variable definition.


読み込み中…
キャンセル
保存