Im not a codenigger

We have Rust now, no need for obsolete languages like C

If you are working with C you most probably will have to touch code written a long time ago. So it is benefical to know how it was done in the unmodern times.

I wish I had gone into medicine instead of programming, isolating yourself in front of a screen all day long gets really old

>>25462398 You will never be a real embedded language.

The modern approach would be to stop using C. It's just a terribly designed language that no new standard can fix.

>>25462463 alternative? there is none tbh

>>25462487 rust doesn't count, 3mb for "hello world"

>>25462491 C++ then. It's also a terribly designed language, but it sucks less than C. And the new standards actually introduce modern features, even though they don't remove all the mistakes from the old standards.

>any book on any programming Jeebus, don't be stupid, that's all it takes. >>25462463 There's nothing to fix. It's perfect.

>Last but not least, C++ has introduced lambdas, and some C compilers might already have them Damn that's based. They should add lambderidoos into C.

>>25462786 C++ lambdas are actually really good. >add lambderidoos into C Just use C++. It's effectively a superset anyway.

>>25462808 >C++ lambdas usecase? there are 0 usecases for this bloat

>>25462823 you can defend bloat like OOP but not this

>>25462823 They are actually used all the time.

>>25462830 >niggers use it so it's good even though it's useless and I can't think of a single example

>>25462830 For what purpose though?

>>25462840 >can't think of a single example Callback functions is one obvious example. Why are Poles consistently the worst posters on KC?

>>25462861 >Callback functions I have no clue what that is and definition is so long and written with so many incel nerd buzzwords that I don't really care

>>25462883 Well, if you ever decide to learn programming, you'll realize how important they are.

Gustedt is a C++nigger who doesn't know C particularly well even though he's in the committee. I've looked at his book and it was just worse than the others. Coverage of new features is nice but nothing prevents you from reading K&R C and/or King's C and filling in the few good things they added to the language later like atomics and checked math. The information in these books isn't outdated, just incomplete.

Gustedt is a C++nigger who doesn't know C particularly well even though he's in the committee. I've looked at his book and it was just worse than the others. Coverage of new features is nice but nothing prevents you from reading K&R C and/or King's C and filling in the few good things they added to the language later like atomics and checked math. The information in these books isn't outdated, just incomplete.

>>25462983 I know you posted as an onion.

>>25462988 How does this happen accidentally? Is he a fake garlic?

>>25463045 Are you telling me you don't proxy KC through different networks based on domain and post using all of them with different personalities? Ach Bernd.

>>25463070 No, I'm not schizo enough for that. And you don't have any anonymity posting as garlic when there are only 2 or 3 of them on this site. Everybody recognizes you.

>>25463094 >And you don't have any anonymity posting as garlic I don't think he cares since he spent years posting bare IP. But he's hard to recognize when posting as an onion.

>>25463120 He only posts as garlic because being Onion is too mainstream. He's the hipster weeb of Kc.

>>25463133 Yeah, I think he wants to be recognized. Btw, you can get a garlic ball without having to use I2P.

>>25462883 >I have no clue what that is Why the fuck do you even start a programming discussion if you don't know basic stuff?

I stopped trying to learn c. Thank you for reminding me to remove my edx account and withdraw from the harvard course

>>25462388 I have partially read it. The content isn't bad, but I don't find it is an easy read. The author isn't that good in writing.

>>25463232 You will never leave your home town now...

>>25463572 How am i supposed to leave? I cant fucking learn it

>>25463581 Learn html and then goto javascript, else, kys.

>>25463581 Its over... Unless you make enough money on patreon by generating AI furry porn.

>>25463581 Don't do it, if you struggle with it. You might just not be cut out for it. That is fine. When you already struggle with learning, you will hate the work with it.

>>25463581 You're a problemless 1st worlder, just enjoy life and forget putting effort into stuff, not that you ever tried.

Thank you, Bernd.

Have you tried "Better C"? Even if you just use a D compiler to compile your C you get modules with __import keyword.

Imagine writing header guards in 2025.

I always wanted to learn C cause of the memes a while ago I tried learning rust, was kinda interesting

>>25463730 If you can't learn C, you won't learn Rust.

>>25463743 I never tried learning C, did the online rust guide almost fully but i already forgot it all

>>25463709 I don't really see the appeal. It just will lead to code that isn't compilable by a C compiler that isn't compatible with anything else.

Is there a guide on how to do things I do very efficiently with python but using C? for example, i need to parse a list with values that forms a matrix... in python it's just a couple of splits in c have to invent something yes im retarded

im going to learn c again. Fuck the shills

>>25463795 No, C is just a terrible language with a terrible standard library. Either get a third party library to do it for you or suffer. Actually, you'll suffer either way.

>>25463800 Try to learn computer architecture while at it and assembly. Everything you read and maybe suffered through not really knowing how this or that is related or what's going in King's book suddenly makes so much more sense.

>>25463812 I wouldn't call it terrible. But yes it has some ugly parts. For the sake of backwards compatibility it never got the remake it deserved.

>>25463795 In Dlang you can do: import std.string : split; str.split(",");

>>25463838 It's terrible. CStrings are the biggest plague programming has ever faced.

>>25463863 They work great for most string operations. >>25463795 getline(), strsep(), strtonum(), strdup(), etc.

>>25463795 Just use numpy. Theres no reason to write applications for full fledged x86 machines with gigabytes of memory in C.

>>25463841 Does this return a char**?

>>25463882 How do you make a substring in C? That's right, you copy the whole fucking string over and over because you need to put a \0 sentinel.

>>25463886 The moment you write a program for full fledged x86 machines with gigabytes of memory in Python, the performance and amount of stuff you can fit in memory is the same as my Nintendo Wii.

>>25463887 It returns a slice of bytes which is char[].

>>25463902 So the split is done just like with strtok()? By writing \0 to the string?

>>25463901 >my Nintendo Wii Omg it gets worse. Do you own any funkopops too?

>>25463901 Numpy is more performant than anything the average cnile can come up in 10 lifetimes.

>>25463915 You don't really pick C because it is fast in execution. You pick it because it is very portable, has only a few dependencies and because the runtime is starting fast.

>>25463912 Unless you modify the array returned by split, it will not copy the array.

import std.stdio;
import std.array : split;
void main()
{
  string a = "abc";
  auto b = a.split("b");
  writeln(&a[0]==&b[0][0]);
}

This will output true because it's both "a" at the same address.

And there is no \0 in a D string

>>25463978 You pick C if you're forced to, either because you're doing low level programming on some shitty platform that doesn't even have a C++ compiler or working on a project that was started many years ago when C was still considered a sane option.

>>25462388 >So please do yourself a favor Thank you, Bernd! I was looking for exactly this. Do you have a similar book for C++? I've learned these languages like 20 years ago, and would like to get up to date with my coding practices.

>>25464061 The only features they added will make your program slower.

why should you use the modern standards when literally all the good programs were written in old standards and are way faster than any modern shit?

>>25464082 All good programs adapt to the new standards.

>>25464089 I know C++ got modules years ago. At least on paper. Do they actually work now?

btw Bjarne never even wrote a compiler. He wrote a shitty and slow transpiler that translated his clusterfuck to C.

>>25464082 One strong reason is that today's machines have more than 1 core. And AMD is launching these chiplet CPUs that are essentially NUMA on a chip where there's huge latency between nodes and one node can't use all the memory bandwidth which standards haven't even caught up to yet.

>>25464077 That is the beauty of C. They mostly don't add shit to it. I hate this with other languages. It is like inflation on you knowledge base.

>>25464112 Does it at least work with the standard library with popular compilers like gcc and clang?

>>25464128 _Generic and auto come to my mind. There were thousands of other issues but they had to pick comparatively useless shit.

>>25464139 I guess it is what they could agree to.

>>25464131 Gcc and clang have some support for modules, cmake too, but I haven't really tried it. Not sure to what extend the standard library works with them.

>>25464077 Thonx. How would someone get up do date with his coding-practices then? I think that best practices have changed a lot to reduce memory-leaks and such.

>>25464160 Maybe it works with some flags but you can't just compile an import <iostream>; with clang++. I tried just now. C++ fucktards can't do anything right.

>>25464175 You get up to date by dropping C++, same as it was 40 years ago. Except 40 years ago you had Lisp as the obvious "language with lots of features like C++ and that doesn't suck unlike C++," but today you also have Rust.

>>25464219 I like programming microcontrollers. Which rust-compilers can you name that work on those?

>>25464229 At that point C++ is too bloated for microcontrollers, use C.

>>25464240 I like using objects to implement things like datastructures, instead of suffering through functions that pass pointers to pointers to structs.

If you can, use a language that has booleans.

>>25464240 I also like encapsulation a lot. Even cheap microcontrollers like ESP32 now are multicore and have at least 4MB in flash, so we're not living in the time when such microcontrollers were only doing simple things. So tools that encapsulate things are pretty helpful. Of course my C is also outdated, but at least in my experience, it quickly turns into a shitshow once projects reach a certain degree of complexity.

>>25464252 >>25464277 Great, you can do all that in C. Also, Rust supports ESP32.

>>25464293 So does Dlang

>>25464303 Might be a fine language, I don't know.

>>25464263 Doesn't have C boolean in its newest iteration?

>>25464373 It has had booleans since before the standard. 0 and NULL are false, everything else is true.

>>25464373 No to this day there are only macros in stdbool.h which you have to import every time.

*#include

>>25464424 C23 introduces a bool type.

>>25464460 C23 introduces "Predefined Boolean constants". Which means you won't need to type #include <stdbool.h> anymore. However it does not introduce a bool type. https://en.cppreference.com/w/c/language/bool_constant

assert(true  1 && 0  false);

>>25464482 Your link says >Keywords true and false represent predefined constants. They are non-lvalues of type bool. >assert(true 1 && 0 false); That also works in c++.

>>25464482 Your link says >Keywords true and false represent predefined constants. They are non-lvalues of type bool. >

assert(true  1 && 0  false);

That also works in c++.

>>25464524 You're right. Anyway having to include stdbool every time is a bitch.

Considering it's 2025 I bet not everyone is using C23 yet.

>>25464524 But c++ reduces int to bool in this case

>>25464564 And many never will. The language should really be rebooted by Unix hackers because letting it be run by corporate, freetards, C++jeets, and gay furry niggers has been disastrous.

>>25464578 You can ask Bjarne if he writes you another compiler. He can call it C+++.

>>25464578 You can ask Bjarne if he writes you another transpiler. He can call it C+++.

>>25464570

assert(true  2 && 0  false);

fails

assert(true  bool(2) && 0  false);

works Fucking KC formatting.

>>25464578 Having languages run by corporate doesn't have to be bad. Java was just fine run by Sun. Having multiple corporates run a language also can work. I am only a bit hesitant with newer languages. I think it is a real downside of C#, Go, Swift, Dart that are mostly run by a single big tech company. It might even have started with C# that the influence a single company tents to be too strong to make the language and environment good.

you dont need this thingy anyway, dropping related books for noobs: beej's guides for near-fluent/proficient in some other lang tanenbaums modern os's stuff, try to do some basic versions of concepts discussed in the book in C as you go

I have to write nothing but python and C at work and I dont why but I hate writing python because there are trillions of ways to do somethin while in C there are like 3. Doesnt matter anyway, last 3 months I just stopped giving a fuck and let 90% of work be done by LLMs. Got a raise for being so productive. Im very thankful for the retard boomers at work dooming AI and having no idea of what its capable of because they feel threatened by it. I can do their job in a quarter of the time without having read 50 books.

>>25464639 >Java was just fine run by Sun. Do the public static void main string args dance.

>>25464742 I don't see a problem with it. Java just was C++ and OOP done right.

https://en.cppreference.com/w/c/compiler_support/23 woah, gcc fully supports see 23 nao, kool >>25462530 wake me up when everything supports modules >>25464093 hehe https://en.cppreference.com/w/cpp/compiler_support/20 >>25464639 >C# debugger was the thing where microcucks had you by the balls so you had to use their tooling thus licensing bullshittery was unobvious then all of the sudden samsung made a foss debugger for dotnet

>>25464730 >I hate writing python because there are trillions of ways to do somethin while in C there are like 3. It's the other way around. C stdlib is so small that you have to reinvent everything every time you write a program. In Python you import a function. "There should be one-- and preferably only one --obvious way to do it." - Tim Peters

>>25464639 >Having languages run by corporate doesn't have to be bad. Java was just fine run by Sun. It uses a build system definitions written in XML. When it was released, it only ran on high-end workstations. To this day, the runtime can make simple programs use gigabytes of memory. And all of this for abstractions that provide no tangible benefit. Java could well be the language that exemplifies why corporate can't be in charge of a language. Cue the hello world enterprise edition.

I’m going to use pascal.

>>25464846 >C stdlib is so small that you have to reinvent everything every time you write a program I feel like you are agreeing with me there is only so much you can do with the standard lib so there isnt really anything to think about unless you do really abstract, high level stuff. I write probably on the lowest level possible (raw bytes) with very constrained ressources (not more than a few megabytes of memory). I dont have to think a lot because I can not import something like boost. My python stuff on the other end is very high level and there are infinite ways of doing sometimes all having upsides and downsides and figuring out which is the best is shit. Its like being overwhelmed in american supermarket and not buying anything or the same thing again because there is too much choice.

>>25464900 >not more than a few megabytes of memory Isn't that enough to afford proper strings instead of Cstrings?

>>25464920 There is no way saving 4 or 8 bytes per string (and in turn turning O(1) into O(n) and O(n) into O(n^2) all over the place) is ever worth it.

>>25464856 Maybe that can happen, but there was also Java ME that did run on potato phones.

>>25464920 No, we do really complex real-time stuff already with the memory we have. Today I was forbidden from adding six u32 to a struct because it would be too much of a waste

>>25464900 Stdlib utility matters for small programs. Language features matter for large programs. For small programs, it may well be that some stdlib function in some language already has most of your program written for you. For large programs, the stdlib of any language is going to be largely useless, and what really matters is how much the language lets you express with how little. In large programs, you often find that almost every single language's features are largely useless and don't actually help you write a briefer, more efficient program and C shines simply because its lack of features means it doesn't have the harm of useless features. In small programs, many scripting languages will provide useful facilities and you don't have to do much, but I still wouldn't use them anyway because that is possibly the only benefit most of them provide for a laundry list of downsides, and we're talking about small programs here, I and anyone who tries have enough practice to write them faster than the pyjeet can google solutions and copypaste them for all but the simplest 1-liners. >>25464931 You also save in code and registers. And you're jerking off over theoretical nonsense for when you're dealing with hundreds of megabytes of data or more when the average program just wants to scan and print strings sized in tens of bytes each. Gain some experience programming.

>>25464939 Go write us some Java Card code and show us how great the language is.

>>25464988 Yeah, my point was just about that I personally like writing C much more because I do "simpler" stuff with it and its very nice for that since there arent so many options. My simple C code is good and perfect for what I do. However when I do very complex and ressource heavy dataframe transformations in python I always know that there is a (by far) better way than using standard library. What I want to do isnt it possible with pure python (without language bindings) it would so slow it would take days to do something I do with pandas in minutes because the numpy is just C.

>>25464900 >>25465031 It sounds like your problem is high vs low level programming rather than C vs python.

>>25464704 thanks, Bernd

>>25465037 Absolutely, it wasnt about shilling for some langauge

>>25465016 That is the power of wagies using json to store game data relating to the in game stores where the player can buy vehicles, nigger rigging their own json parser, and loading the entire in game store for no reason on every loading screen instead of only when the player tries to buy something and only what he's looking at. I can write a program that decodes an entire 100GB UHDBD including all the streams in it with 1 CPU core to take a screenshot of the first frame too.

>>25465073 Guess what, sane programming languages can do that easily without giving you footguns like this.

Are there some guidelines of how to write good C-programs that are larger yet remain organized? I found the objectorientation that C++ and Python provides always pretty good to not lose track of things. Does something similar exist for C?

>>25465085 There is no C "footgun" here. Wagies would do the same in Python, Rust, Java, assembly, Pascal, whatever.

>>25465095 No other language iterates over an entire 10MB buffer when you ask it to parse a few characters.

>>25465109 C doesn't either. The Windows implementation of scanf did. And guess what, Windows still sucks no matter what language you write in it.

>>25465085 >people shouldn't be able to work with memory because I am to retarded for it

>>25465016 Isn't parsing with scanf not cumbersome? Seems more like a task four regex.

By the way, Rockstar hasn't actually fixed the issue in GTA Online's loading screens. They just nigger rigged a replacement for the Windows scanf that doesn't call strlen() on a buffer several times while linearly scanning it (quadratic). The problem is still there, the same is still slow to read for on reason and a large part of the process is spent parsing a giant json object with a nigger rigged json parser which is an operation that shouldn't be done at all.

>>25465112 I'm not gonna check each implementation, but from what I read it's not just windows. >>25465148 I wouldn't expect a regex to be faster than sscanf.

Is it still possible to make money with C?

>>25465164 lol

>>25465165 Why? Regex is just an automaton getting its state changed by a stream.

>>25465165 And the very idea of strlen, spending O(n) time to figure out something you should already know, is just braindead. Putting it in random functions, whether in the stdlib or your own, is like having landmines in your code. There is a reason why no modern language does this.

>>25465298 >Forbidden >You don't have permission to access this resource. btw https://reviews.freebsd.org/D29007

>>25465312 So freebsd only fixed this after the gta5 article. My link works in Tor even. It's a bug report for glibc with the same problem. Clearly it wasn't just windows.

>>25465356 And it's not an issue with C, but its implementations. And it's already fixed in at least a few of them. Although having scanf available at all is a big defect in C, the API is terribly broken. And the code that is calling scanf shouldn't be running in any loading screen in the first place. Also, guess the runtime of scanning, printing, copying, or doing some operation on the whole string or any arbitrary position in it in UTF-8. ...linear. Most programs don't just get the length of the string and are done with it, that's an useless operation, they operate on the string starting at some character position and up to the string's length or some other limit before the string's length. Operating on the string up until some limit is linear in both cases. So you made an operation that by itself is useless constant, but any time you do anything significant with the string it's still linear. And what did you lose? Let's look at Rust: https://doc.rust-lang.org/src/alloc/string.rs.html#362 The Rust `String` type is actually just a `Vec`. What's a `Vec` in Rust? It's a length and a `RawVec` according to https://doc.rust-lang.org/src/alloc/vec/mod.rs.html#397. What's a `RawVec`? Following the code it says it has a `PhantomData` which is just a marker that occupies no space and a `RawVecInner` which is defined as a pointer to an array of bytes, the capacity, and a reference to the allocator. https://doc.rust-lang.org/beta/src/alloc/raw_vec.rs.html#88 So now your Rust string on a 64-bit architecture is at least 3 allocations: reference to Vec, the Vec itself, and the array of bytes Vec points to. 1 of these allocations (the array of bytes) has to be on the heap and incurs heap allocation overhead, and you have 8 bytes of length, 8 bytes of capacity, 8 bytes of pointer to the array of bytes, and however many bytes a reference to the allocator takes (I would hope it's a function pointer so 8 bytes). 32 bytes of overhead + 1 heap allocation overhead (it's variable but 16 bytes minimum on glibc, how many is it in Rust?) and 3 places in memory that most likely have no cache locality, but at least in a best case scenario the whole vec (except the array of bytes it points to) can be on 4 registers. Now what's a C string on a 64-bit architecture? 2 allocations: a reference to the array of bytes, and the array of bytes itself which may or may not be on the stack, heap, or some data section and so it doesn't necessarily have heap allocation overhead. 1 byte for the terminator. That is, your overhead is 1 byte and you have 2 places in memory that most likely have no cache locality, but at least the reference to the array of bytes can be on 1 register. Now let's see the runtime of string operations: Parse a `key=value` pair: C: O(n) Rust: O(n) Case fold a string: C: O(n) Rust: O(n) Duplicate a string: C: O(n) Rust: O(n) Read a string: C: O(n) Rust: O(n) Write a string: C: O(n) Rust: O(n) Convert a string to integer: C: O(n) Rust: O(n) String length: C: O(n) Rust: O(1) Are you going to write a program that gets the string length over and over until Rust is faster or are you going to write a real program that does some useful operation which has the same runtime complexity on both, but has better cache locality, less code, less memory overhead, and less register overhead in C? Mind you, Rust has a simpler read-only `str` type which reduces overhead, but also introduces overhead because Rust code (including the stdlib) will use generics so it can accept any of `str`, `String`, `Path`, and `PathBuf` and that will produce several versions of the function in the machine code, further ruining cache locality and adding even more memory overhead, while C uses the same `char *` and the same code for all of that. So which is faster? C.

>>25465669 >Are you going to write a program that gets the string length over and over Did you not just see a real world example of exactly this happening? >So which is faster? C. C is never faster.

>>25465761 I found jeetcode that is running for no reason no matter what implementation it has and that gets the string length over and over for no reason. The equivalent can be done in any language: no language has any breaks that prevent you from using a shitty format like json, writing your own shitty parser, and then parsing something large with it for no reason.

>>25465779 The only reason that parser was shitty is because the C stdlib is broken beyond hope.

You're going round in circles, go to bed you two

>>25465827 Tbh I just quickly type a reply when I get a (you) and didn't even read most of his wall of text.

>>25462433 I actually wrote my home automation in rust and it was a really pleasant experience.

>>25462491 As usual with rust critics, skill issue.

>>25462491 As usual with rust critics, skill issue.

>>25462861 >Why are Poles consistently the worst posters on KC? Low IQ + delusions of grandeur

>>25463915 >Numpy is more performant than anything the average cnile can come up in 10 lifetimes. The performance critical parts of numpy are written in C/C++, this is the case for pretty much any reasonably fast python libary. You're incredibly clueless. https://github.com/numpy/numpy

>>25464229 >>25464240 >>25464252 https://github.com/esp-rs/awesome-esp-rust https://blog.logrocket.com/complete-guide-running-rust-arduino/ https://www.alexdwilson.dev/how-to-program-raspberry-pi-pico-with-rust Writing rust on microcontrollers is pretty straightforward. It is also not more "bloated" than C. Most of the time Rust and C code can be written in such a way to compile down to almost or exactly the same assembly if written well, especially for smaller programs.

>>25464277 I actually took the ECS system of Bevy and used it on ESP32. I was working on 2 projects in parallel, home automation and a game. I was learning Bevy and it's ECS at the time and looking for a simple idea to play around with the ECS myself, and when i saw how small the executables are when you compile bevy with minimal modules i realized this could easily fit on a µC. https://bevyengine.org/learn/quick-start/getting-started/ecs/ Bevy is super modular, I only used ~5 out of 50 systems bevy has, only the core, scheduler, ECS and that's pretty much it. All the fancy 3D render shit never has to be touched at all. I had multiple systems in mind that all interact and was pondering about a good code structure, which tbh is something I am still quite weak on as a developer. Also when using an abstraction like ECS, you don't really have to think about your overall program structure. You just write all your systems which interact with the ECS and it magically all works. If you're worried about turning your C code into a mess, this for sure won't. Not sure if i'm genius who discovered something amazing or retard too lazy to structure my shit properly. Worked and was a pleasant experience though.

>>25464564 I know a guy who does amazing work, he uses C99 religiously.

I cobble together what I need while referencing K&R. No one can stop me.

>>25465669 >Duplicate a string: >C: O(n) >Rust: O(n) In C you have to first iterate over the string to find out the length, so you can allocate the right amount. So while both are O(n), C has to iterate over the source string twice and will take longer to copy it. Same with the rest. All strawmen.

>>25463915 Anything in Python you consider fast is simply a library written in a faster language.

>>25466936 All performance critical parts of python, its standard library and 3rd party libraries are written in C/C++. Which is why it's a good idea to glue them together in python instead of reinventing them in C/C++ yourself.

>>25470742 You are aware that you can use the libraries directly instead of using the bindings in some slave language?

>>25470752 No, you cannot use a python library directly in another language.

>>25470808 Numpy is the binding, retard. Internally it uses BLAS and LAPACK written in Fortran.

>>25470716 C doesn't have to iterate twice over the string for most operations, although it does have to do it for duplication in the worst case, you can optimize it in the common case by preallocating a buffer smaller than the overhead for a string in Rust. In any case, learn more about machine architecture before making such posts, the cache/memory fetch will dominate the runtime, and iterating twice will only make one cache/memory fetch unless your string is too big to fit the cache which it isn't, and rust strings are guaranteed to be in 2 different cache lines minimum because of the heap allocation.

>>25470889 Nigger we were talking about a heap allocated string with the pointer or struct allocated on the stack in both languages.

>>25470849 Some parts of it may be bindings of other libraries, but numpy is more than that and more useful than they are individually. And python is a better language for code that's not performance critical.

>>25470910 >And python is a better language Compared to what?

>>25470919 Anything really.

>>25470921 So you think Python is better than JavaScript, Java, C, C++, C#, D, Ruby, PHP, Swift, Go, Rust, Kotlin, TypeScript, Dart, Julia, R, Scala, Haskell, Elixir, Lua, Erlang, Odin, Zig, Nim?

Or Crystal or pony

>>25470908 The String structure itself in Rust can be allocated anywhere, but the array of bytes it points to is always in the heap. You could have String in the stack and the array it points to internally in the heap, or String in the heap and the array it points to somewhere else in the heap. These 2 allocations will always be in a different cache line, firstly because the overhead of a string in Rust is so great it already occupies a whole cache line, secondly because either the allocations are in different regions or because modern allocators try not to place 2 heap allocations near each other because that's also bad for performance. In C you always have 1 place in memory for a string and 1 byte of overhead, common strings will be entirely in 1 cache line.

>>25470935 Yes. There is a reason why so many new projects that don't have to be written in a specific language use python. Just look at all the AI stuff.

>>25470952 >but the array of bytes it points to is always in the heap. Usually it's the same for C and this isn't a debate about Rust. There are other competing languages that can allocate on the stack. I'm not a Rust expert, so I can't argue about Rust with you

>>25470955 The reason is that professionals don't care about what they're doing and just want to get it over with and will do whatever everyone else is doing.

>>25470955 Delusional.

>>25470952 In C++ short strings are optimized to be stored on the stack. In Rust probably too. C doesn't solve this problem at all, because you also have the pointer and the data in different locations.

>>25470964 >>25470971 Lol cope.

>>25470978 In Dlang empty strings have a null pointer. In Rust probably too. Unlike C where an empty string requires a null terminator.

>>25470997 And C++ <string> that just wraps C strings.

Unlike in C++ in Dlang and Rust strings aren't classes, so they don't suffer from the overhead.

>>25470978 >you also have the pointer and the data in different locations. You have that in any string structure no matter what. even if it's not a literal pointer it could be e.g. an immediate with the location baked into an instruction. In Rust the least overhead you could have is: >String structure in registers >array of bytes with text in the heap In C the least overhead you could have is: >char * in a register >array of bytes with text in one of the data sections or the stack In Rust the most overhead you could have is: >reference to String structure in the heap >String structure in the heap >array of bytes in the heap In C the most overhead you could have is: >reference to char * in the heap >array of bytes in the heap >In Rust probably too. The array of bytes in the `str` type can easily go in the stack, the array of bytes inside the `String` type can in theory be optimized that way but today's compilers can't do that because String includes a reference to the allocator and the compiler doesn't know the allocator's semantics. >>25470997 Rust empty strings aren't a null pointer.

>>25470997 >>25471012 C++ is better than that, up to 16 bytes can be stored in the string object directly on the stack. Only when the string is longer, memory is allocated on the heap and the string object stores a pointer to it. And all that happens automatically and transparently to the programmer, something C-niles could only dream of. >>25471047 What overhead?

Just thinking of strings and python makes me sick. It's worse than Javascript which uses UTF-16. Python uses random encodings under the hood and will magically make your string 4x larger in memory if you use an emoji: >ASCII, Latin-1 (UCS1), UCS2 or UCS4. https://stackoverflow.com/questions/1838170/what-is-internal-representation-of-string-in-python-3-x

>>25471062 >You have that in any string structure no matter what. You literally don't, see >>25471067

>>25471075 Ebin, I didn't know that. Now check out C++ string spaghetti: https://www.bunkus.org/2021/03/converting-a-c-code-base-from-boostfilesystem-to-stdfilesystem/

>>25471100 Just what you'd expect.

Internally Windows still uses UTF-16 either way, right? So there shouldn't be any benefit in having Windows handle the conversion from UTF-8 to 16 instead of doing it yourself. This is what happens when you fail to acknowledge that encodings exist and people should and want to use UTF-8.

>>25471100 >On POSIX systems this means no conversion which matches how MKVToolNix is coded: std::filesystem::path receives a UTF-8 encoded narrow string & stores it as-is internally. Am I missing something? That sounds exactly how it should be done.

>>25471165 The article sayin it done work wight on de Windows an de MacDonalds. Lot of pepo likin de windows an de macdonalds.

>>25471164 Yes, Windows uses UTF-16 internally. Every Windows API that accepts a different encoding will convert to UTF-16. This UTF-16 may then be converted again to something else because fat32l uses UCS-2, but this is the only case of another conversion being done inside Windows I'm aware of, though it's so huge there may be more. And macOS uses UTF-8 and UTF-16 at the same time and doesn't even do it properly because different normalization forms are treated as different files. Meanwhile on Linux all the encodings are used at once, Linux filesystems don't even have a text encoding, they just treat filenames as an array of bytes that can't contain '\0' and what encoding you use to interpret that array of bytes as is up to you, some file you got from an ext2 flash drive may well be SHIT-JIZZ.

>>25471203 >Meanwhile on Linux all the encodings are used at once, Linux filesystems don't even have a text encoding They all use UTF-8 now, so it's not so bad anymore.

>>25465669 It is absolutely nonsensical to compare dynamically allocatable strings with low-level raw pointers. I have yet to see C code which you can't replicate in Rust and have it compile down to identical assembly, especially for trivial small examples like you're talking about. You seem to generally obsess about small irrelevant details. Most people do not care about performance and most code is not performance optimized. Yet in general Rust code benchmarks show rust to be ~3% slower than C without trying much, while Rust provides an ABSURD amount of value for that tiny speed bump to the user. Value you will only see once you've worked in a large codebase, something I suspect you never did. Which explains why you fail to see any value in what rust provides over C.

>>25471165 The filesystem abstraction in C++ doesn't actually help you one bit and you still have to deal with all the OS differences yourself, which includes dealing with C++'s string abstraction which also doesn't actually help you one bit with each operating system's string preferences, and then it's a huge article describing the full pain of having to work with that. But yes, strings are probably UTF-8 in C++ on Unix, and on today's Unix systems filenames could be anything, although lots of programs assume UTF-8 which isn't a bad approach. Rust is a language that gets filenames right. Strings are always UTF-8. Filenames are filenames, their internal behavior is abstracted away, but you can tell Rust's filename abstraction to do something with the filename and a string using various functions and they'll do what they can and explicitly fail somehow if it can't.

>>25471299 >although lots of programs assume UTF-8 which isn't a bad approach It's the only viable approach. There is no reason to use anything else and no truly deterministic way to figure out an encoding without any metadata.

>>25471299 It's interesting that you blame C++ for windows problems when just yesterday you were defending C and blaming its problems on windows (which turned out to affect all platforms).

>>25471299 setting the progress codepage to utf8 actually fixes most windows utf8 filename woes. You can almost get away with using -A APIs only. https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page

>>25471067 >up to 16 bytes can be stored in the string object directly on the stack It depends actually. See: https://devblogs.microsoft.com/oldnewthing/20240510-00/?p=109742

>>25471376 >progress codepage I like this. >>25471346 Because you lack the IQ to understand the difference between something that isn't stated anywhere in the C standard and can be written in any language and shouldn't be written in any language, and something that is mandated by C++ and that you have to work with.

>>25471404 Ah, so windows made their retarded implementation because it was required by the standard, got it. Poor guys, why is microsoft always being bullied?

>>25471404 What it does is essentially set windows's default conversion method to utf8<->utf16, which is the only sane one anyway. All the -A APIs magically start working and std::filesystem::path::string()/wstring() start doing correct conversion too. Much much better than std::u8string, which is so bad that it must be on purpose somehow.

>>25471394 Yes, the details are implementation defined, but looks like only clang uses a different size than 16.

Job havers of /int/. What kind of a job do C programmers have these days? What kind of a person would write modern C and in what type of projects?

>>25471489 I did some work for a micro controller for an insulin pump. But that wasn't modern C, just plain C99.

>>25471489 >C programmers >Job havers

>But most programming languages evolve at such a pace that finding a book like that even few years after its release, you will be reading about deprecated standard library functions, outdated syntax and practices that have been tossed into the bin. Nigger why do you even need a book for that, just read the API doc online

>>25471515 >what is embedded

>>25471513 Yeah that's why I'm kind of curios. I've written some programs for routers and such but even those things have so much memory and power that you can just write everything in python. So I'm wondering where modern C is used that isn't ANSI C legacy stuff. I rarely see any job openings for C programmers in Finland.

>>25471535 Europe doesn't develop dogshit anyway

>>25471543 >what is outsourcing

>>25471543 there's plenty of dogshit and goodshit developed upon europe

>>25471535 The toolchain included a static code checker that was full of Misra shit. So more modern versions of C wouldn't even have mattered, I guess the Misra rules would have forbidden anyway.

>>25471543 I would guess that the German automobile industry is still has a use for C programmers.

>>25471535 >I've written some programs for routers and such but even those things have so much memory and power that you can just write everything in python. What are you on about? Just the implementation of Python is enough to exhaust the entire storage of a router and a single Python program is enough to exhaust the entire memory of a router.

console
# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 2.3M      2.3M         0 100% /rom
tmpfs                    14.1M     68.0K     14.0M   0% /tmp
/dev/mtdblock6          512.0K    268.0K    244.0K  52% /overlay
overlayfs:/overlay      512.0K    268.0K    244.0K  52% /
tmpfs                   512.0K         0    512.0K   0% /dev
# free -h
             total       used       free     shared    buffers     cached
Mem:         28780      17544      11236         68       1932       5160
-/+ buffers/cache:      10452      18328
Swap:            0          0          0

>>25471598 You can even run docker on an industrial router these days if you want to be silly.

>>25471627 Docker is just a fancy chroot. The kernel give you this for free.

>>25472077 Chroot is not free.

>>25472077 Docker for "isolation" is seccomp but even worse, and seccomp is already terrible. Docker for shipping programs has no usecase other than hte ignorance of the programmer. Chroot is deprecated by landlock.

>>25472097 Free as in free beer

uppity

>>25471563 >The toolchain included a static code checker that was full of Misra shit. So more modern versions of C wouldn't even have mattered, I guess the Misra rules would have forbidden anyway. Sounds lovely, I am sure it was far superior to the developer experience Rust could provide.

[code][/code]

>>25475930 I would prefer it over Rust anytime. Just alone I already know C and it didn't change since 2000 in this case. I neither know Rust, nor do I think it is stable. C is comfy because you know what to expect and it won't surprise you in the next 10 years. Honestly I am kind of sick of new languages. I doubt the world would be worse, if we just had stopped to invent new languages or language features in 2000. C, Java, Python and PHP and we would be covered.

>>25480434 >C, Java, Python and PHP and we would be covered. Here we have a shiteater.

[code][/code]

>>25480434 > I don't know Rust but have an opinion

>>25484076 I don't have to know it. The tool that I own is always better then the tool I don't own.

>>25484093 Both are freely available. fuck captchas.