Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

How to C

Name: Anonymous 2016-01-08 14:23

https://matt.sh/howto-c

Very good read for anyone that wants to write this outdated language in 2016.

Name: Anonymous 2016-01-08 14:26

>>1
Developers routinely abuse char to mean "byte" even when they are doing unsigned byte manipulations. It's much cleaner to use uint8_t to mean single a unsigned-byte
How is "uint8_t" cleaner than a simple and elegant "char"? These faggots desperately need a renaming of all the standard types. In particular, getting rid of the "_t" bullshit is imperative.

Name: Anonymous 2016-01-08 15:06

>>2
Nobody guarantees you that char is unsigned, therefore you can get all sorts of undefined behavior that way.

Name: Anonymous 2016-01-08 15:32

>>3
use unsigned char

Name: Anonymous 2016-01-08 15:41

>>4
B (Byte) 1 char
u1 (void.h) 2 chars
uint8_t (stdint.h) 7 chars
unsigned char 13 chars
Making life harder for yourself?

Name: Anonymous 2016-01-08 15:46

Unsigned:signed
1c:B Byte C Char
2c:W Word S Short
4c:D Dword I Int
8c:Q Qword L Long
There is no reason to use anything longer besides masochism

Name: Anonymous 2016-01-08 17:17

>>4-5
Go back to your dead BBS, FrozenAnus.

Name: Anonymous 2016-01-08 17:31

Why did the jews add _t to everything?

Name: Anonymous 2016-01-08 17:51

>>8
_type=_t

Name: Anonymous 2016-01-08 18:33

>>9
But it's already obvious that it's a type from its syntactic position. No other language needs "_t" in type names.

Name: Anonymous 2016-01-08 19:39

>>6
Unsigned:signed:float
1c:B Byte C Char H Half-precision(16bit)
2c:W Word S Short F Float(32bit Single-Precision)
4c:D Dword I Int T Double(64bit Twofold-Precision)
8c:Q Qword L Long E Long Double(80 bit Extended Precision)
V:void

Name: Anonymous 2016-01-08 21:45

>>10
But my Hungarians!

Name: Anonymous 2016-01-08 21:49

>>>/hackernews/

Name: Anonymous 2016-01-08 22:04

This article reads like those Java spoofs on "Hello, World!" which gets longer and longer as "abstractions" and "best practices" are applied.

Serious Poe's law shit going on here.

Name: Anonymous 2016-01-08 22:19

>>14
He does have one sound piece of advice:

So, do NOT do this:

#ifndef PROJECT_HEADERNAME
#define PROJECT_HEADERNAME
.
.
.
#endif /* PROJECT_HEADERNAME */

Do THIS instead:

#pragma once

Name: Anonymous 2016-01-09 7:00

I usually get an anger boner when I read something like "Modern XYZ" or "XYZ in 20XX" -- implying the "old" (and often proven) way of doing something has suddenly become obsolete.
As far as I can tell, there's 2 different reasons for such opinions to occur:
1. The model of something has changed, like an API, which is only sometimes changed for good reason (e.g. 3D APIs, server backend stuff, etc).
2. Someone wants to sell you an opinion ('sell', as in book, seminar or vendor-lock-in).
This one though, just seems to be someone (partially) uninformed. Especially the stdint.h promotion seems to be baseless and useless: there's solid reasons for using char/int/unsigned (also, they wouldn't be in the standard anymore if they were 'obsolete'/dangerous, like gets()).
I do have to agree with him on size_t (although I try to avoid it) and -Wall -Wextra, though.

Name: Anonymous 2016-01-09 7:48

>>15
That's non-standard C and should thus not be used.

Name: Anonymous 2016-01-09 8:24

Use your i's

Name: Anonymous 2016-01-09 9:59

https://matt.sh/howto-c
It's an accident of history for C to have "brace optional" single statements after loop constructs and conditionals. It is inexcusable to write modern code without braces enforced on every loop and every conditional. Trying to argue "but, the compiler accepts it!" has nothing to do with the readabiltiy, maintainability, understandability, or skimability of code. You aren't programming to please your compiler, you are programming to please future people who have to maintain your current brain state years after everybody has forgotten why anything exists in the first place.

Name: Anonymous 2016-01-09 12:50

>>16
solid reasons for using char/int/unsigned
What are they?
char is always obviously u8
int is always at least 16 bits (so use uint_fast16_t for loops) and you'd be insane to say you wanted different behaviour on 32/64 bit platforms
unsigned should be default because it is far more likely what you want, and you should "opt-in" to the slightly different behaviour of some signed operations, e.g. mod/div/rem/quotient

Name: Anonymous 2016-01-09 13:55

>>20
char is always obviously u8
No it's not, the signedness of char is implementation defined.

Name: Anonymous 2016-01-09 14:24

>>21
And how is that a solid reason for using char?

Name: Anonymous 2016-01-09 15:35

>>20-21
char is also not always 8 bit, but always represents one byte on the given architecture (even if it's 9bit or something else exotic)

Name: Anonymous 2016-01-09 19:32

>>23
A byte is always 8 bits. A char is the smallest addressable word.

Name: Anonymous 2016-01-09 21:03

>>23,24
As per IEC 80000-13 in fact.

Name: Anonymous 2016-01-09 22:15

>>24-25
char is CHAR_BIT, C standard requires it to be at least 8 bit; POSIX mandates CHAR_BIT == 8

Many Texas Instruments DSPs have 16 or 32 bit chars; machines with 36 bit architectures, e.g. DEC PDP-6/10, could have 5, 6, 7, 8 or 9 bits per character (+ 4, 0, 1, 4 or 0 spare bits) and due to C standard requirement of at least 8 bits per char, they implemented 9 bit chars.

Name: Anonymous 2016-01-09 22:27

>>26
Machine-dependent data type width is unportable. char and int are thus shit.

Name: Anonymous 2016-01-09 22:57

>>26
POSIX mandates CHAR_BIT == 8
Only POSIX 2008 and maybe 2003

>>24
Are you claiming that PDP10 had 8-bit bytes?

>>25
Prove it

Name: Anonymous 2016-01-10 4:18

>>28
"In English, the name byte, symbol B, is used as a synonym for octet. Here byte means an eight-bit byte. However, byte has been used for numbers of bits other than eight. To avoid the risk of confusion, it is strongly recommended that the name byte and the symbol B be used only for eight-bit bytes."

Name: Anonymous 2016-01-10 6:31

>>29
This proves nothing.

Name: Anonymous 2016-01-10 7:53

>>30
Sometimes a cigar is a penis. But in the other nine hundred ninety nine million nine hundred ninety nine thousand nine hundred ninety nine out of one billion times, it is just a cigar. It is then usually a safe bet to call a cigar a cigar, and not quibble over the slight chance you may be cutting a penis open when you roll that blunt.

Name: Anonymous 2016-01-10 8:01

>>31
Except that this is totally irrelevant to what >>24,25-chans claim.

Name: Anonymous 2016-01-10 10:40

ATTENTION! This thread is derailed. Please respond to >>27 in order to continue pertinent discussion.

>>28
I cited a standard. Just look it up, you goit.

Name: Anonymous 2016-01-10 10:48

What the shit is everyone talking about?!?
A char is always:
able to hold a decimal value from 0 to 127
able to hold 8 binary digits
able to hold an ASCII character (ANSI, too, but that's a little more complicated when CHAR_BIT isn't 8)
of size 1
And if you don't see the implications of this, then just continue using uint8_t.

Name: Anonymous 2016-01-10 11:16

>>27
If the minimum range of int is guaranteed sufficient for your purposes, then letting the system use its default register width is ideal.

Name: Anonymous 2016-01-10 12:37

>>29
We are talking about C programming language, not English language.

>>34 and to some extent >>27
Not all platforms implement uint8_t, for example 16 bit TI DSPs. Because of that, char is much more portable type, because it means smallest addressable type on given architecture (except when architecture allows smaller chars than 8 – the lower limit of C standard). And as >>34-kun stated, sizeof(char) is always 1. Types whose size is not a multiply of char have no right to exist on such architectures in a native way.

Name: Anonymous 2016-01-10 14:45

>>35
As int is at least 16 bits wide, it is more ideal in that situation to use uint_fast16_t or uint_least16_t depending on whether you are iterating or storing in an array.

>>36
Not all platforms implement uint8_t
OK: http://www.cplusplus.com/reference/cstdint/
However, UINT8_MAX is defined to be 255, so uint8_t (or whichever of uint_fast8_t or uint_least8_t is chosen if it does not exist) is still more useful than char. Refer back to >>27.

Name: Anonymous 2016-01-10 17:10

the stdint.h on mingw introduces a new exciting
type that force cludges for anyone attempting
to use it. Source:
typedef unsigned uint32_t; //line 40
this typedef requires 2 extra types
(long,unsigned long)
to be handled as special cases and
typedef signed char int8_t;//line 35
requires handling an extra(char) type which is considered
distinct from signed char.

Name: Anonymous 2016-01-10 20:33

>>38
You need a wider terminal mate.

Name: Anonymous 2016-01-10 21:05

Can /prog// write a better "How to C"?
Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List
All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode + RSS -