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

Generics in C without void* or macros – enabled by psychec

github.com

Post reply on HN
Print view View original

21–30 of 74 posts

Re: Generics in C without void* or macros – enabled by psychec

#21

Post by klingonopera »

jackewiehose wrote: post #9
TorKlingberg wrote: post #6

No void* or macros, but requires a special compiler frontend.

Yes, that was confusing. "Look, you don't need to use these C-features if you use another language than C."

C++ 14, Haskell and Python.

One of the reasons I'm actually going for pure C in this modern day and age, is that I can just write a small program, without having any other dependency.

I'm sure the same could be said for C++, too, but for some reason, with my setup (GCC 5.1.0 with MinGW on Windows 7), I'm averaging around 800KB on C++ vs 80KB on C, for the (mostly) same code. EDIT: It appears that exception-handling is one of the reasons the binary is bigger in C++ than C.

I mainly write code for embedded devices, so whatever programs I write on x86 is to interface with those devices, hence I'm quite comfortable staying with C.

Re: Generics in C without void* or macros – enabled by psychec

#22

Post by Crinus »

klingonopera wrote: post #20
Crinus wrote: post #19

Earlier quoted context omitted.

The problem with C++ is that in addition to generic functionality, it also brings a ton of other baggage that even if you do not use, you still pay for (e.g. personally i really dislike how slow C++ compilers are). Though TBH i wouldn't use OP's preprocessor either as i think that void* and macros are perfectly fine.

Exceptions being one of the notable pieces of baggage...

Yeah, though i'm not sure if exceptions really slow down compilation and in some compilers you can disable them anyway. Also you can redefine new to return null on failure, though if you are going to use new, delete, etc might as well bite the bullet and use the entire language anyway (and instead of redefining new, use a template that does the allocation and initialization based on some common convention and a macro that causes an error whenever new is used since you can ensure no exceptions will be thrown... at least from new - but IMO a better way is to just stick with C and avoid the tarpit that is C++).

Re: Generics in C without void* or macros – enabled by psychec

#23

Post by klingonopera »

Crinus wrote: post #22
klingonopera wrote: post #20

Earlier quoted context omitted.

Exceptions being one of the notable pieces of baggage...

Yeah, though i'm not sure if exceptions really slow down compilation and in some compilers you can disable them anyway. Also you can redefine new to return null on failure, though if you are going to use new, delete, etc might as well bite the bullet and use the entire language anyway (and instead of redefining new, use a template that does the allocation and initialization based on some common convention and a macro…

...my compile times rarely take more than a minute, so I can't really relate to that, but exceptions will slow down execution and add an overhead to the binary's file-size.

Re: Generics in C without void* or macros – enabled by psychec

#24

Post by wvenable »

Crinus wrote: post #19
blazemaster wrote: post #13

I don't really understand what the point of all this is, and why anyone would consider using this in a real-world application they're developing. There's already a C-like language which lets you write type-safe generic programs: it's called C++! And if for some reason you really want or need to restrict yourself to using C language features (almost) exclusively, you can disable RTTI, exceptions, and use a technique t…

The problem with C++ is that in addition to generic functionality, it also brings a ton of other baggage that even if you do not use, you still pay for (e.g. personally i really dislike how slow C++ compilers are). Though TBH i wouldn't use OP's preprocessor either as i think that void* and macros are perfectly fine.

One of the reasons C++ is so complicated is that you don't pay for the features that you don't use. If you wanted generics in C, you can easily use C++ without any of those other features (baggage, if you will) and not pay for it.

Heck, you could define a few macros and make it impossible to use any baggage features you don't like.

I've used C++ in a pretty tight embedded environment and it was great.

Re: Generics in C without void* or macros – enabled by psychec

#25

Post by wvenable »

klingonopera wrote: post #23
Crinus wrote: post #22

Earlier quoted context omitted.

Yeah, though i'm not sure if exceptions really slow down compilation and in some compilers you can disable them anyway. Also you can redefine new to return null on failure, though if you are going to use new, delete, etc might as well bite the bullet and use the entire language anyway (and instead of redefining new, use a template that does the allocation and initialization based on some common convention and a macro…

...my compile times rarely take more than a minute, so I can't really relate to that, but exceptions will slow down execution and add an overhead to the binary's file-size.

Exceptions don't generally slow down execution -- they usually have zero runtime cost if they're not thrown making them better than error returns for performance. However, the exchange is, as you said, that they do add a lot of overhead to the file-size.

Re: Generics in C without void* or macros – enabled by psychec

#26

Post by Crinus »

klingonopera wrote: post #23
Crinus wrote: post #22

Earlier quoted context omitted.

Yeah, though i'm not sure if exceptions really slow down compilation and in some compilers you can disable them anyway. Also you can redefine new to return null on failure, though if you are going to use new, delete, etc might as well bite the bullet and use the entire language anyway (and instead of redefining new, use a template that does the allocation and initialization based on some common convention and a macro…

...my compile times rarely take more than a minute, so I can't really relate to that, but exceptions will slow down execution and add an overhead to the binary's file-size.

Heh, this reminds me of the Abrash quote about optimization mentioned a few days ago (from his black book):

> We're so used to slow software that when a compile-and-link sequence that took two minutes on a PC takes just ten seconds on a 486 computer, we're ecstatic—when in truth we should be settling for nothing less than instantaneous response.

(from https://github.com/jagregory/abrash-black-book/blob/master/s...)

Personally i'm annoyed when my compile times take more than a few seconds :-P

Re: Generics in C without void* or macros – enabled by psychec

#27

Post by Crinus »

wvenable wrote: post #24
Crinus wrote: post #19

Earlier quoted context omitted.

The problem with C++ is that in addition to generic functionality, it also brings a ton of other baggage that even if you do not use, you still pay for (e.g. personally i really dislike how slow C++ compilers are). Though TBH i wouldn't use OP's preprocessor either as i think that void* and macros are perfectly fine.

One of the reasons C++ is so complicated is that you don't pay for the features that you don't use. If you wanted generics in C, you can easily use C++ without any of those other features (baggage, if you will) and not pay for it. Heck, you could define a few macros and make it impossible to use any baggage features you don't like. I've used C++ in a pretty tight embedded environment and it was great.

You may not pay for them (generally) in terms of execution time, but you pay for them in terms of compilation time and language complexity.

Re: Generics in C without void* or macros – enabled by psychec

#28

Post by Crinus »

klingonopera wrote: post #21
jackewiehose wrote: post #9

Earlier quoted context omitted.

Yes, that was confusing. "Look, you don't need to use these C-features if you use another language than C."

C++ 14, Haskell and Python. One of the reasons I'm actually going for pure C in this modern day and age, is that I can just write a small program, without having any other dependency. I'm sure the same could be said for C++, too, but for some reason, with my setup (GCC 5.1.0 with MinGW on Windows 7), I'm averaging around 800KB on C++ vs 80KB on C, for the (mostly) same code. EDIT: It appears that exception-handling i…

Are you sure it isn't debugging information that bloats the executable? Try a strip --strip-all your.exe and see if it is still that big.

Re: Generics in C without void* or macros – enabled by psychec

#29

Post by wvenable »

Crinus wrote: post #27
wvenable wrote: post #24

Earlier quoted context omitted.

One of the reasons C++ is so complicated is that you don't pay for the features that you don't use. If you wanted generics in C, you can easily use C++ without any of those other features (baggage, if you will) and not pay for it. Heck, you could define a few macros and make it impossible to use any baggage features you don't like. I've used C++ in a pretty tight embedded environment and it was great.

You may not pay for them (generally) in terms of execution time, but you pay for them in terms of compilation time and language complexity.

If I don't use them then language complexity doesn't matter. Compilation times might be a factor assuming that turning them off doesn't also decrease that (which it might).

Re: Generics in C without void* or macros – enabled by psychec

#30

Post by klingonopera »

wvenable wrote: post #25
klingonopera wrote: post #23

Earlier quoted context omitted.

...my compile times rarely take more than a minute, so I can't really relate to that, but exceptions will slow down execution and add an overhead to the binary's file-size.

Exceptions don't generally slow down execution -- they usually have zero runtime cost if they're not thrown making them better than error returns for performance. However, the exchange is, as you said, that they do add a lot of overhead to the file-size.

Regarding error handling, I agree with this author[0], and find the C-based approach much better than C++'s try/throw/catch methods.

Regarding execution times, I don't know from first-hand experience, I did some research and found this[1]. The third sentence in that reply ("The error code is not sensitive to the percentage of occurrence") is AFAIK wrong (because of speculative execution, I believe?), but the rest seems quite solid.

[0]: http://250bpm.com/blog:4

[1]: https://stackoverflow.com/a/52513707

Post reply on HN