Programming thread

  • Want to keep track of this thread?
    Accounts can bookmark posts, watch threads for updates, and jump back to where you stopped reading.
    Create account
Anti Snigger said:
something to check for with C++ compilation is functions using the thiscall convention, where first arg, (this), is passed into %rax
Click to expand...
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.
 
Last edited:
Enne said:
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.
Click to expand...
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
 
Dr. Charles Forbin said:
it's most likely the decompiler getting confused
Click to expand...
no it does follow the assembly
Code: 
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
 
analrapist said:
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.
Click to expand...

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.
 
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.
 
Last edited:
ChompChomp said:
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.
Click to expand...
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
 
ChompChomp said:
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...
Click to expand...
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.
 
ChompChomp said:
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.
Click to expand...
camelCase for functions snake_case for variables
shrimple as that
August Levasseur said:
Now, type specifier on a different line, I still can’t stand that.
Click to expand...
oh yeah thtk's codebase is fucking awful for that reason (and various others)
1768826401147.png
 
Last edited:
canalCrab said:
Why the fuck is error double indirected?
Click to expand...
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
1768828494336.png
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
 
Last edited:
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.
 
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.
 
Private Tag Reporter said:
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.
Click to expand...
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.
 
Penne Dreadful said:
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.
Click to expand...
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.
 
DumbDude43 said:
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.
Click to expand...
essentially this but filenames should be flatcase
also its called PascalCase REEEEEEEEEE
 
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.

Rango Dango said:
also its called PascalCase REEEEEEEEEE
Click to expand...
Only when the variables StartWithUpper (not startWithUpper) edit: that's what you were talking about nvm
 
ChompChomp said:
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.
Click to expand...
Reminds me of a good post.
1768840038671.png
 
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:
1768841355719.png

God endorses:
  • PascalCase for types and functions.
  • sparse_snakecase for variables and fields.
  • UPPER_SNAKE for defines/global constants.
  • unreadablecase for keywords.
 
You must log in or register to reply here.
Back
Top Bottom