Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My personal C coding style as of late 2023

nullprogram.com

Post reply on HN
Print view View original

371–380 of 466 posts

Re: My personal C coding style as of late 2023

#371

Post by lelanthran »

AdamH12113 wrote: post #350
rurban wrote: post #262

Earlier quoted context omitted.

I"m even not agreeing with the const part. The standard did define const API"s, so why shouldn"t we follow? I know that C const are only half of C++ consts, but still. Still catching const errors somewhere because I do use const in APIs. I only agree with "Declare all functions static except for entry points". s8(s) is only for literal strings, it should be called s8_c instead and keep s8 for the default ctor. The st…

Can you explain the static functions thing? What’s the benefit of declaring all functions static if you’re compiling them as a single translation unit anyway?

You don't get the linker complain of multiply defined symbols when your code is linked in as a library to some other project.

If you're writing code that never gets reused, then it's fine, no need for static functions.

Re: My personal C coding style as of late 2023

#372

Post by uxp8u61q »

lelanthran wrote: post #367
uxp8u61q wrote: post #291

Earlier quoted context omitted.

> I prefer functions over classes. Then use functions? > no mangling of exported names, the binary is re-usable as API. Not once in my life have I seen someone use a binary as an API. > in the long term, the C source code is more re-usable in other projects than C++ ones. I don't even know what you mean by that.

> I don't even know what you mean by that. He means that if you write your library in C it is callable from Python, Java, C++, Ruby, PHP, Python, Perl and more.

You can also do that with C++.

Re: My personal C coding style as of late 2023

#373

Post by uxp8u61q »

lelanthran wrote: post #368
uxp8u61q wrote: post #289

Earlier quoted context omitted.

Smart pointers alone make the switch worth it. Why wouldn't you want that?

Because it comes with everything else, notably it includes all the footguns or C and then adds orders of magnitudes more. Unless you're a solo developer, this is not a win. It's no accident that C++ is the only language in which its proponents have to self police their own teams to only use a subset of the language.

Sometimes I feel like I'm taking crazy pills when I go on HN. What footguns are there in C++ that aren't there in C?

Re: My personal C coding style as of late 2023

#374

Post by lelanthran »

uxp8u61q wrote: post #373
lelanthran wrote: post #368

Earlier quoted context omitted.

Because it comes with everything else, notably it includes all the footguns or C and then adds orders of magnitudes more. Unless you're a solo developer, this is not a win. It's no accident that C++ is the only language in which its proponents have to self police their own teams to only use a subset of the language.

Sometimes I feel like I'm taking crazy pills when I go on HN. What footguns are there in C++ that aren't there in C?

Everything around the rules of destruction in derived classes from a base class with/without a virtual destructor.

How about capture of values in a lambda within a loop? How to prevent a template expansion from killing you build process? When are move semantics sufficient for the std container classes and when are they not? What's the order of construction of multiple objects at file scope? When should a copy constructor be written so that the default shallow copy is prevented?

All of those are footguns, because if you do them wrong the program has runtime bugs without any compiler warnings.

They are all absent from C.

I'm typing on a phone, so won't go into detailw, but if you want to make such an insane claim, bear in mind that Scott Meyers himself said that C++ is too complex for him

You are not disagreeing with me when you make that claim, you're disagreeing with one of the world's foremost experts on C++.

Re: My personal C coding style as of late 2023

#375

Post by lelanthran »

uxp8u61q wrote: post #372
lelanthran wrote: post #367

Earlier quoted context omitted.

> I don't even know what you mean by that. He means that if you write your library in C it is callable from Python, Java, C++, Ruby, PHP, Python, Perl and more.

You can also do that with C++.

No, you cannot.

Because C++ without exceptions is not C++, and those languages cannot catch exceptions, nor call overloaded functions, nor delete or create objects using new and delete, nor refer to fields with classes, nor call methods on objects.

Re: My personal C coding style as of late 2023

#376

Post by wrs »

avgcorrection wrote: post #337
smithza wrote: post #335

Earlier quoted context omitted.

k for konstant

Yes, that's what it stands for. What's the point of using any prefix at all?

So you don’t have to wonder if it’s a variable. Old Mac style uses prefixes: kConstant, gGlobalVar, TType, mMemberVar. Remember this was when all coding was done in black and white in a plain text editor.

Re: My personal C coding style as of late 2023

#377

Post by uxp8u61q »

lelanthran wrote: post #375
uxp8u61q wrote: post #372

Earlier quoted context omitted.

You can also do that with C++.

No, you cannot. Because C++ without exceptions is not C++, and those languages cannot catch exceptions, nor call overloaded functions, nor delete or create objects using new and delete, nor refer to fields with classes, nor call methods on objects.

> Because C++ without exceptions is not C++

Write exception-free external APIs. It's not that hard.

> call overloaded functions

Write an API that doesn't overload functions?

> nor delete or create objects using new and delete

Write an API around that. You'd need to do it in C anyway.

> nor refer to fields with classes

What?

> call methods on objects

If you can call a function, you can call a method.

Your complaint is basically "you cannot write C++ in Python". Duh.

Re: My personal C coding style as of late 2023

#378

Post by uxp8u61q »

lelanthran wrote: post #374
uxp8u61q wrote: post #373

Earlier quoted context omitted.

Sometimes I feel like I'm taking crazy pills when I go on HN. What footguns are there in C++ that aren't there in C?

Everything around the rules of destruction in derived classes from a base class with/without a virtual destructor. How about capture of values in a lambda within a loop? How to prevent a template expansion from killing you build process? When are move semantics sufficient for the std container classes and when are they not? What's the order of construction of multiple objects at file scope? When should a copy constru…

> I'm typing on a phone

But you have an uncontrollable urge to write here? Someone's holding a gun to your head?

> You are not disagreeing with me when you make that claim, you're disagreeing with one of the world's foremost experts on C++.

I guess that settles everything then. Never mind that you're misquoting him.

Look, if you hadn't written the last two paragraphs, I'd have replied to your points, but they strongly indicate it would fall into deaf ears. You're clearly more interested in entertaining the peanut gallery more than actual discussion.

Re: My personal C coding style as of late 2023

#379

Post by Am4TIfIsER0ppos »

WalterBright wrote: post #163
Uptrenda wrote: post #84

IMO, defining your own types is one step too far. Now everyone who is already familiar with C types has to learn your own quirky system to understand one program. I think it does probably make sense to be specific about the sizes though e.g. using uint32_t over just uint (and expecting to receive some architecture-dependent size you might not get with uint.) These types should be defined in the right header (I think…

The reality is that C `int` is 32 bits in size. Sure, that's not true for 16 bit targets. But are you really going to port a 5Mb program to 16 bits? It's not worth worrying about. Your code is highly unlikely to be portable to 16 bits anyway. The problem is with `long`, which is 32 bits on some machines and 64 bits on others. This is just madness. Fortunately, `long long` is always 64 bits, so it makes sense to just…

Wait... where's plain "long"? I know, you probably know, but that is why you use explicit sizes where you can.

Re: My personal C coding style as of late 2023

#380

Post by lelanthran »

uxp8u61q wrote: post #377
lelanthran wrote: post #375

Earlier quoted context omitted.

No, you cannot. Because C++ without exceptions is not C++, and those languages cannot catch exceptions, nor call overloaded functions, nor delete or create objects using new and delete, nor refer to fields with classes, nor call methods on objects.

> Because C++ without exceptions is not C++ Write exception-free external APIs. It's not that hard. > call overloaded functions Write an API that doesn't overload functions? > nor delete or create objects using new and delete Write an API around that. You'd need to do it in C anyway. > nor refer to fields with classes What? > call methods on objects If you can call a function, you can call a method. Your complaint is…

> Your complaint is basically "you cannot write C++ in Python". Duh.

Maybe it is a complaint, but it's still a fact of life: your code is not reusable without wrapping it in C.

The reality is that C++ is not as reusable as C is: ever wonder why there are so few reused libraries written in C++, while they are so many in C?

Look on your system now - it's filled with C libraries, while the C++ libraries are probably a rounding error.

Post reply on HN