Programming thread

[General Zoider]

something to check for with C++ compilation is functions using the thiscall convention, where first arg, (this), is passed into %rax

also check for vtables/RTTI expecially if you have ida and the plugin because it can quickly find and name the functions in the class into reasonable values somtimes.

 

[Dr. Charles Forbin]

I don't know if I'm missing something but wouldn't that code being generated be correct if there's no checking actually being done on the new call actually allocating properly? I wouldn't say it's on the compiler exactly to make sure you don't do invalid pointer accesses, non-C like C++ code and OOP both give me a headache so maybe I'm misunderstanding.

In terms of execution, yeah it ends up having the same outcome

But I'm almost completely certain the compiler did not generate this (unless optimizations were turned off), it's most likely the decompiler getting confused. new doesn't even return NULL on a failure unless you specifically use a variant that doesn't throw an exception. IIRC calling a member function on a null pointer is UB anyway so an optimizing compiler shouldn't even consider the possibility

MSVC has a lot of faults, but there's no way it's that retarded, even if this is from an old ass version

 

[Rango Dango]

it's most likely the decompiler getting confused

no it does follow the assembly

PUSH 434
CALL operator_new
ADD ESP, 4
TEST EAX, EAX
JZ SHORT 00456A3A
MOV ECX, EAX
CALL AnmVM::constructor
PUSH ESI
MOV ESI, EAX
MOV EBP, EAX
CALL AnmVM::reset
POP ESI
JMP SHORT 00456A51
00456A3A: XOR EAX, EAX
PUSH ESI
MOV ESI, EAX
MOV EBP, EAX
CALL AnmVM::reset
POP ESI

old msvc is giga-retarded
and im pretty sure touhou 11 was compiled with optimizations enabled

 

[Foghotten]

K&R or what? If you want to get good at C, another place to start learning would be GNU Lib C: https://sourceware.org/glibc/manual/latest/html_mono/libc.html You follow that up with the musl docs, and you'll have a good sense of the things that people do with C and build some opinions about what's better for what.

This book specifically. It was kinda late where I live so I forgot the language's older than me and written about like 9 billion times lol

Anyways, with the replies I've had so far (and holy shit, thanks for the insights and demos, that was so cool), I've made the decision of re-learning programming with SICP starting tomorrow. I still code like I have three full stack projects due for the end of the week, and no time to learn universal CS fundamentals. I don't think banging my head into walls trying new projects on my own will do me good long term.

Most of you guys suggested GNU Lib C, and while it looks like a very juicy read, it feels like I'd trap myself learning the language itself rather than CS wisdom that would carry over whatever tech I'd use. This is something I did with JS out of necessity last year, and I would rather start fresh with a new language, which looks to be Lisp right now; it's readable, and looks esolang-tier vile at first glance coming out of C and web-dev languages, which means it's the perfect place to start over.

I'm not looking forward to this book absolutely kicking my ass for months, but between that and turning into YandereDev, I know what I'm choosing.

 

[ChompChomp]

Not sure if it was already covered,but I automatically hate you if you do any of the following things:

• Opening curly braces on a dedicated line. Yes, I know even the C Programming Handbook uses this calamity of a style, but it shouldn't because it's less readable. Need more space? Add a comment! Which brings us to...
• Inline comments. It shows laziness, most are cut-off due to width restrictions (we're a mobile-first framework, ha ha! ), and most code is written top-to-bottom, so if you comment above something, we'll probably know what you're referring to, unless you suck at writing, in which case it won't matter anyway.
• Use camelCase in Python, C, or C++. Or, any other language that doesn't explicitly state that deplorable grammatical style as the de facto style choice.
• Unless there's a good reason, use double+quotation marks for strings. Single quotes are too hit-and-miss for things like automatic execution and variable interpolation.

 

[Dr. Charles Forbin]

Not sure if it was already covered,but I automatically hate you if you do any of the following things:

• Opening curly braces on a dedicated line. Yes, I know even the C Programming Handbook uses this calamity of a style, but it shouldn't because it's less readable. Need more space? Add a comment! Which brings us to...
• Inline comments. It shows laziness, most are cut-off due to width restrictions (we're a mobile-first framework, ha ha! ), and most code is written top-to-bottom, so if you comment above something, we'll probably know what you're referring to, unless you suck at writing, in which case it won't matter anyway.
• Use camelCase in Python, C, or C++. Or, any other language that doesn't explicitly state that deplorable grammatical style as the de facto style choice.
• Unless there's a good reason, use double+quotation marks for strings. Single quotes are too hit-and-miss for things like automatic execution and variable interpolation.

All of this ranges from good practice to excusable

The real faggots are the ones who indent with spaces. You will pry my 8-width tabs from my cold dead hands

 

[August Levasseur]

Opening curly braces on a dedicated line. Yes, I know even the C Programming Handbook uses this calamity of a style, but it shouldn't because it's less readable. Need more space? Add a comment! Which brings us to...

I didn’t like them either until I watched a Tsoding clip where he just offhandedly explained how he could easily search for the next function definition in Emacs by just looking for the next line that began with a curly brace. In other languages you can just search for a function declaration keyword, but C has no such keyword, so unless you do opening semicolon on a new line it would be very annoying to do that kind of incrimental search.
Now, type specifier on a different line, I still can’t stand that.

 

[Rango Dango]

Use camelCase in Python, C, or C++. Or, any other language that doesn't explicitly state that deplorable grammatical style as the de facto style choice.

camelCase for functions snake_case for variables
shrimple as that

Now, type specifier on a different line, I still can’t stand that.

oh yeah thtk's codebase is fucking awful for that reason (and various others)

 

[canalCrab]

camelCase for functions snake_case for variables
shrimple as that

oh yeah thtk's codebase is fucking awful for that reason (and various others)
Ver archivo adjunto 8445123

Why the fuck is error double indirected?

 

[Rango Dango]

Why the fuck is error double indirected?

no clue EDIT: because thtk_io_seek and thtk_io_read take that as arg, which take it because thtk_error_new (a macro to thtk_error_func_new) takes it as an arg, and FINALLY thtk_error_func_new takes it as a double pointer for no reason because its always used dereferenced

funnily enough thats essentially a char*** because thtk_error_t contains just char *message
in general theres a lot wrong with the code

...at least it works

 

[DumbDude43]

snake_case for variable names (both local function variables and data members of structs/classes)
UPPER_SNAKE_CASE for global variables (mostly constants) and also for naming the entries of an enum
camelCase for function names
UpperCamelCase for class/struct names (and any other kinds of 'custom data type' names) and also file names


every compiler for every language should be forced to immediately reject any code that deviates from this as ill-formed.

 

[Private Tag Reporter]

snake_case is two keystrokes for shift plus underscore, camelCase is one keystroke so it will not cause as much hand strain.

Get fucked snake_case_losers.

 

[analrapist]

Lotta folks in here sleepin on skewer-case (which some spiritual-browns call kebab-case, but we're speaking English, so we translate words accordingly). Of course, you can't use it in places where - is read as an infix subtraction operator.

 

[Penne Dreadful]

snake_case is two keystrokes for shift plus underscore, camelCase is one keystroke so it will not cause as much hand strain.

Get fucked snake_case_losers.

Any variable is completed by your editor after being typed for the first time. The extra hand strain happens once while you benefit from snake_case every time you see it.

 

[ADHD Mate]

Any variable is completed by your editor after being typed for the first time. The extra hand strain happens once while you benefit from snake_case every time you see it.

Idk. For me reading camelCase is pretty much the same as snake_case. But now every identifier has extra width, which corresponds to longer lines overall. Which sometimes can become significant.

 

[Rango Dango]

snake_case for variable names (both local function variables and data members of structs/classes)
UPPER_SNAKE_CASE for global variables (mostly constants) and also for naming the entries of an enum
camelCase for function names
UpperCamelCase for class/struct names (and any other kinds of 'custom data type' names) and also file names


every compiler for every language should be forced to immediately reject any code that deviates from this as ill-formed.

essentially this but filenames should be flatcase
also its called PascalCase REEEEEEEEEE

 

[Nitro!]

Digging into C++ lately and my variables are all smashitalltogethercase. For a project that is go, go, go, make it work, it feels right. Other languages it's snake_case and camelCase is always wrong.

also its called PascalCase REEEEEEEEEE

Only when the variables StartWithUpper (not startWithUpper) edit: that's what you were talking about nvm

 

[Rango Dango]

Digging into C++ lately and my variables are all smashitalltogethercase

yeah thats the reason i make my filenames flatcase
its stdio not StdIo

 

[Enne]

Not sure if it was already covered,but I automatically hate you if you do any of the following things:

• Opening curly braces on a dedicated line. Yes, I know even the C Programming Handbook uses this calamity of a style, but it shouldn't because it's less readable. Need more space? Add a comment! Which brings us to...
• Inline comments. It shows laziness, most are cut-off due to width restrictions (we're a mobile-first framework, ha ha! ), and most code is written top-to-bottom, so if you comment above something, we'll probably know what you're referring to, unless you suck at writing, in which case it won't matter anyway.
• Use camelCase in Python, C, or C++. Or, any other language that doesn't explicitly state that deplorable grammatical style as the de facto style choice.
• Unless there's a good reason, use double+quotation marks for strings. Single quotes are too hit-and-miss for things like automatic execution and variable interpolation.

Reminds me of a good post.

 

[Lard Shart]

God calls functions in PascalCase, it does not matter you think. That's pure truth.

Enlighten yourselves by taking a good look some code that was written with help from God, for talking to God:


God endorses:

• PascalCase for types and functions.
• sparse_snakecase for variables and fields.
• UPPER_SNAKE for defines/global constants.
• unreadablecase for keywords.