/cpg/ - C Programming General

Ok so this thread is epic.

Who here actually uses C unironically and has written good / no meme software with it.

Attached: Keemstar.jpg (746x1200, 158K)

Other urls found in this thread:

man.openbsd.org/tolower.3
man.openbsd.org/towlower.3
twitter.com/AnonBabble

*Non meme

Hourly reminder that neither of C and C++ can't do basic string operations without a third party library.

Attached: Screenshot from 2019-01-08 21-07-47.png (1926x906, 188K)

Basic string operations are easy as fuck what kind of brainlet needs a third party library for this shit

Attached: 1496638848688.jpg (1280x720, 88K)

Lmao at your life for needing the handicap of strings. You probably use vectors too. I bet you write some gud code, Karly.

Go ahead, surprise me
SOUR GRAPES LMFAO

Attached: Screenshot from 2019-01-09 16-45-49.png (552x180, 17K)

>reddit
Try coming up with your own opinions sometime

doesn't newer c/c++ standards have native unicode support

Who cares? Statically or dynamically linking to a string library has the same bloat/performance cost if it's first or third party.
>but muh first party string lib
What's the difference? Code quality? It's all open sores anyways. I'd rather have a 3rd party library fill one niche well than have a hilariously bloated stdlib written by devs stretched too thinly.
>neither can't
Work on your grammar before posting here again

Attached: 1524249012094.png (4000x4000, 84K)

Oh yeah, I love writing the same 4 lines of resizing code over and over again.
`std::vector` by itself shits all over the basic tenets of today's C fetishist.

C died the day I learned printf can write to the stack.

>direction flag
>requires using asm
This has to be bait, right? How do they think literally any other language works? Have you ever read the sores code for a language like Rust or Go? They ALL defer to assembly for tasks that can't be adequately described by language builtins.
Feel free to reply when you actually understand how "modern" programming languages work under the hood.

Attached: 12442512387763.jpg (750x578, 49K)

>without a third party library
string.h, strings.h, ctype.h, wctype.h, retard
man.openbsd.org/tolower.3
man.openbsd.org/towlower.3

They do.

based openbsd poster

>i asked pcj
>i asked Jow Forumsprogrammingcirclejerk
>asking a circlejerk subplebbit to do something unironically
>using plebbit unironically

>wctype.h

this.

sizeof(char) is not 1 byte any more. (technically it still is, nut chars are got too much fat)

>Who here actually uses C unironically and has written good / no meme software with it.
I work with C every day, and I've, among other things, written a library for accessing an NVMe drive directly from CUDA kernels.

>sizeof(char) is not 1 byte any more.
sizeof(char) is always 1, it is defined to be this way in the standard.

char represents the smallest addressable unit on the system, regardless of that unit's size.

Depending on your definition of "support", older standards had this also through multibyte strings.

is this pic real? if it is i might actually watch that anime

I can't find any measurements anywhere of how badly C++ templates actually increase compile times.

I've heard things like "I went to 10 minutes to 4 seconds" when abandoning C++ for C. Is there any other info?

C++ only increases compile time if you rely heavily on templated generics and don't use precompiled headers. A software project has to be of a significant size in order for this to be a real problem.

>C++ only increases compile time if you...
lie, using C++ "features" at all seriously increases compile times.
>A software project has to be of a significant size in order for this to be a real problem.
ie. Anything bigger than anons fizzbuzzes.

>NO U LIE!!!!!!
Not an argument. Why don't you post the measurements user originally asked for then, if you're so sure it's true?

>ie. Anything bigger than anons fizzbuzzes.
No, i.e. compiling boost for the first time.

I also remember some fizzbuzz recursion article somewhere that showed a compile time of 4 seconds to 0.3 seconds due to templates.

I really think there's just very little information on C++'s compile times and how they're effected by the language features and std.

Because that's really the main divide between C and C++. Performance, both at runtime and compiletime. Not so much in the languages, but more their methodologies.

So let's see it in action, test case is Retard ctard

>I really think there's just very little information on C++'s compile times and how they're effected by the language features and std.
It's because its mostly exaggerated by opponents of C++,

While it is true that templates can significantly reduce compile time, most "real-life" programs would not rely that much on template magic. The fizzbuzz recursion thing you're talking about is probably using templates to make the compiler do fizzbuzz, which of course makes it take a long time.

No I meant the other way around. Using templates, even for a simple recursion program upped the compile time to 4 seconds from 0.3.

>Basic string operations

We're past that here.

The first part of that post is correct though.

C++ is in fact slower to compile, but it gets overblown by Cniles, same with the ABI issue (notice that C++ has a de facto standard ABI as well).

It may be slower to compile, but I think it's worthwhile knowing exactly what causes that.

This.

>but I think it's worthwhile knowing exactly what causes that.
Generic templated code. Say you have a function that uses a generic type. Then you use that function with an integer. The compiler must then generate the specialized function for integers, which takes N time. Then say you make another call to the same function, but with a float. The compiler must now generate the same function specialized for floats, which also takes N time.

Without precompiled headers and stuff like partial specialization and full specialization, these things take time. But as and correctly identified, this is wildly exaggerated by people who like tho shit on sepples.

It's edited

Attached: 49410035.jpg (770x646, 49K)

But the stuff that really takes time is when you use templates recursively and partial specialization.

It's hard to test that in the wild.
How often do you come across large C++ codebases that were rewritten in C or viceversa with the intent of changing for analytical reasons?

Based and redpilled

>It's hard to test that in the wild.
Yes it is, that's why you don't find any of the "measurements" the original user is requesting.

>How often do you come across large C++ codebases that were rewritten in C or viceversa with the intent of changing for analytical reasons?
Practically never. It also doesn't help that idiomatic C++ is very, very different from idiomatic C, which for all intents and purposes make them different languages with their own paradigms and good practices etc.

Not as easy as it looks.

Attached: a5d1fbd2-467a-480c-b0ac-7cb7c2cc9165..png (719x837, 67K)

Now do it without any helper functions.

It's incorrect