Thread 106204653

Learnt it in uni when I learnt programming and then skipped to C++ and never looked back.
And yeah... I get the appeal. Made a quick 2D game with SDL.
The experience is very different from my C++ routine cause there is no "fake work".
I didn't spend hours trying to get the best and most scalable architecture, which patterns to use, figuring out if unique_ptr were the way to go or if i'd stick to shared_ptr... While still making something pretty clean cause of my experience in OOP
I was facing the algorithmic part right away, no (very little) class API design or whatever
in C++ for my personal projects I spend more time making things look nice or handy than doing real coding that matters at runtime.
is this why this language is shilled so hard on this board?

>>106204653 (OP)
All you need is a hash table, it's like 100LOC.

We think c is better for low level programming but c++ more for accademic use!

>>106204653 (OP)
LMAO i feel like such a retard now for bothering with C++.

Like in Java it at least all made sense and went smoothly.

But trying to write a game, doing things with a simple functional approach still seems way better than trying to generalize a bunch of shit.

>>106204653 (OP)
I don't think its really correct to conceptualize C and C++ as different languages. At their core they are the same language. They are the same where it matters, that being semantics. C++ is pretty much just syntactic sugar.

>>106204653 (OP)
>no (very little) class API design or whatever
now build an actual 50kloc system with it, retard. for extra challenge, make it portable.

>>106204653 (OP)
Unsubscribe

>>106204653 (OP)
you can write efficient data transformations in any language, but C forces your nose into it because there is nothing else to worry about. the trick is to learn thinking like this (what is the least amount of work that the machine needs to perform to solve the problem?) and then apply it in your Java enterprise backend codebase. you'll delete tons of crappy indirections, suddenly see why the whole thing is so damn slow (the high level algorithm is factored wrong, sinply reordering the steps avoids pointless waste etc.) and you'll feel like a real engineer instead of having debates or agonize about "clean code". you can do a lot worse than stick to C for a while

>>106204802
syntatic sugar that gives you things constexpr, an entirely different type system, and features that cannot be replicated in C like l-value reference and r-value references

>>106204677
Is this why everything is a table in Lua?

C++ doesn't imply strictly following OOP. You're given access to C with extra features you can chose to use.

>>106204653 (OP)
>is this why this language is shilled so hard on this board?
the reason you see discussions about C popping up everywhere its not because it gets shilled
its because genuinely that many people use and love c on this board

about making things handy though-
once you will start writing decently sized projects, you will spend a noticeable amount of time thinking about your interfacing
its optimal to recreate certain features of sepples to a certain degree

also if you work on gcc check force inlining
it has all the advantages of being a separate function while being a zero cost abstraction.
i use it to contain spaghetti and emulate templates - i force inline duplicate code.

>>106204915
>you can write efficient data transformations in any language
not all languages provide a fine enough control to do that
but its 100% true that what one learns with c can be applied to most in not all languages

>>106205025
No, Lua tables are more complex than that.

>>106204915
>>106205147
cont
or maybe yeah
its dialectic
"efficient"
but whats the cutoff for considering a program being efficient?

>>106204653 (OP)
>Learnt it in uni when I learnt programming and then skipped to C++ and never looked back.

>>106205147
if you rawdog data structures it applies to any language

the problem is that in high level interpreted languages like Python you often get 100x-1000x constant speedup by using vectorized data structures implemented by native binaries so you're forced to give up granular control to get performance

a retarded quadratic algorithm in numpy is often faster than a logn one in python, for practical input sizes

>>106205209
>you rawdog data structures it applies to any language
proof set please

>>106205240
what the fuck do you mean, proof?

a linear language native loop scanning over a native array is faster than a quadratic native language loop scanning over a native array in any language that has native loops and arrays

>>106204653 (OP)
>shared_ptr
there is like a 1% chance you actually need this

>>106205302
raii is for larger projects where you have to account for retarded devs

>>106205209
>the problem is that in high level interpreted languages like Python you often get 100x-1000x constant speedup by using vectorized data structures implemented by native binaries so you're forced to give up granular control to get performance
i was more thinking in the direction of
>but is it even python at this point?
its a compiled binary
you can call these in many languages...
like in shell? that would muddy the waters even more because at what point does it stop being a language and it begins to be an interface to the os?
and speaking of which you can execute shell commands form a c binary, or even directly use syscalls
sooooo
at what point does c stop being a language and it becomes an interface for the os?

its just dialectical autism
i understand what you mean and i think were saying the same thing but with different words

>>106205095
it's quite good for interfacing c libs and dod is quite easy to write nowadays. that's about it though

>>106205308
thats unique_ptr
shared_ptr is reference counting, and has a much more niche use case

>>106204653 (OP)
>if unique_ptr were the way to go or if i'd stick to shared_ptr.
Rust doesn't have this problem

>>106205334
well, yeah. size_t is essentially an index that's smaller than a pointer to throw around everywhere rather than allocating more for a raw pointer. it's quite efficient for realtime objects

>>106205328
The STL is very useful.

>>106205325
>is it even python at this point?
Kind of a nonsensical question that underageb&s like to trip up on. Whenever you make a system call or use an external library interface you don't care what language that shit is written in, you care what language you're writing the calling code in.

Using numpy you get to do all the latte sipping onions guzzling pythonista shit in the actual code you write - fancy slicing and indexing, runtime introspection, adding class methods dynamically at runtime, whatever - but the underlying code you're calling through the library interface is written in a different language, to do things that aren't possible to do in python. just like when you make a system call in C the compiler has to insert assembly instructions to trap into kernel mode, which you can't do in C itself. yet the code around this system call can use the "high level" features of C (which is what you care about since that's what you're writing).

>>106205302
once you get used to using them it's hard to go back.

>>106205362
counterexample or stfu

>>106205404
>you don't care what language that shit is written in, you care what language you're writing the calling code in.
but then in absolute you could write your program entirely in something else and just call it from python and say its a python program
and if this is true then we could as well say that all programs are shell programs then ^^

eh, dont mind me
im baked
i like to play with high level concepts as a passtime and see how i could bend them into absurdity

>>106205369
What. On most machines a size_t is the same size as a pointer. If you want your index to take up less space then you should be using uintN_t based on the upper bound of the number of elements you will be putting into whatever container you're indexing. It is very rare that using a size_t over a pointer will save you any bytes unless you're developing for some weird architecture or you built your own toolchain and configured it like a retard.

>>106205302
ARC is nice if you're lazy. std::shared_ptr is convenient if it isn't necessary.

>>106204653 (OP)
Sounds more like a you problem. Everything you're doing in C++ you can still do in C, and everything you're not doing in C you can also not do in C++. This isn't a language thing.

>>106205350
Yes it does, just with Rc & RefCell instead.

>>106205588
>C you can also not do in C++.
you dont have vlas in sepples

>>106205472
I don't get what you're saying here. I explicitly mentioned the numpy example as an EXCLUSION to my statement about universal applicability.

the normal rules of performant code specifically don't apply in cases like this, where external library code can give huge speedups with much worse asymptotics. cache aware programming is similar in many ways but not quite as extreme

>>106205628
>I don't get what you're saying here.
dw its musings of a half insane programmer anyways. it might better not to, kek

>the normal rules of performant code specifically don't apply in cases like this, where external library code can give huge speedups with much worse asymptotics.
>cache aware programming is similar in many ways but not quite as extreme
yeah ofc
and beyond intrinsics theres also gpus
pytorch runs on one i think

>>106205302
i use them all over the place, they're extremely convenient, they make cpp a garbage collected language

ITT: retards get filtered. c++ lives on.

>>106204653 (OP)
I had the same experience, I started off with C++, when it was time to get into C I was really surprised by just how simple and effective of a language it is, everything is so intuitive too, you can just make up a solution and know for the most part it will work.
It's my favorite language ever since then.

>>106204848
*riposte*
I only care about making demos and writing blogs about how great C89 is

Basically every cnile!
>saar i love rewriting HashMap every time i need it because it doesnt exist in the standard library
>also i love not having generics and using void* for everything saaaaaaar

>>106205606
wow VLAs something everyone uses and the earth would stop spinning if we didnt

>>106205865
yea i know
but still. they come in handy sometimes

>>106205095
mu templates god I am so sick of this bullshit, you have one class make some function

so you don't have to make it 10 gorrilion times over...

also bjarne is a convicted fucking bjarne, god fog lord him self

>>106205881
man I am used to danes.. I que speak clear ffs... with him I want go son of a bitch Speak clear bjarne nobody can understand you...

>>106205865
>>106205879
im sure theres some compiler intrinsic which would allow vlas in sepples too btw
but point still stands
c is not exactly the same as c++

and the philosophy is completely different

>>106205606
What's wrong with std::vector ?

>>106205890
>c is not exactly the same as c++
tbq most threat it as c with classes and ignore the new stuff.. you won't believe how normal this is...

>>106205917
dont ask me i barely know sepples
all i know is that a vla is a buffer on the stack whose size you can define at runtime

my biggest problem with c++ is the void pointer type

>>106205949
what are you on about? no you are trolling

you from trønderlag or something troll
void* means just pointer

https://youtu.be/R1BvTzleoOE

Why does C++ put class names in snake_case? Literally no language does this and it is retatded.

>>106205947
You might want to look into C++, this is basic.

>>106205983
how do you allocate on stack at runtime in c++ in a standard way? legit curious.

>>106205924
eh, i was being facetious
i decided to learn sepples now i got decent to good c skills.
its only a matter of learning the oop part now
also i didnt have an incentive to learn sepples until now
its gonna be 3 years im working on one project, and its nature makes it so that theres maybe 10-20% of my code where higher level abstractions would be sane due to perf concerns

>>106205949
void* is mostly a C thing tho. because of no polymorphism.

>>106205978
c implicitly casts any pointer type to/from void*
c++ does not

>>106206032
good

>>106204802
there's a couple of things i wanted to do in c++ that are valid in c but not valid in c++
the more time passes the more different the languages become

>>106206049
void is an uninhabitable type so the c++ rules make no sense retard

>>106206062
yes, there is no reason to allow casts not conforming to inheritance hierarchy

>>106206026
just c style callback crap god I'm drunk prolly find it in some ancient code made 6 billion years ago

instead of ie
char* malloc()
int* malloc()
void* malloc()..

>>106205164
I don't think Roberto was able to go to IKEA back then.

>>106205325
>at what point does c stop being a language and it becomes an interface for the os?
a while ago
https://faultlore.com/blah/c-isnt-a-language/