Hacker News Reader

Comment by WalterBright | Hacker News Reader

Heavy use of macros to do metaprogramming is a strong sign it's time to move to a more powerful language.

On one hand that's obviously true, on the other hand it's just 60 lines of code, which is easier to check and audit than (for instance) a typical std::vector implementation - I don't know what the equivalent is in D, please forgive my ignorance :)

A typical std::vector implementation supports a lot more things, so it's not an apples-to-apples comparison. It's like saying that a horse-drawn carriage is a lot easier to repair than a motor vehicle. It's true, but doesn't really say much.

I don't have this luxury if I want to learn about ffmpeg libraries, its all written in c, almost all media and hardware accelerator libraries are written in c, you go to another language they just bind to c. its soo frustrating but I've no choice but to stick with c.

huh? What's wrong with using the higher level languages if they take care of binding to the C parts for you.

(I know these are far an in-between for ffmpeg, too many leaky abstractions.)

Usually increased build system complexity, outdated manually maintained bindings, etc etc... - in some languages (like Zig) this is really trivial, in other languages it can be much harder.

try to find ffmpeg in go or rust that is < 5 years old and complete. how about intel libva,

Most languages have the ability to call C functions. Use the language that helps you write your code and convert to call the third party API.

For example, a C++ Vector provides a generic container and the code can still call C functions with the underlying array.

This is in the "Doctor it hurts if I do X" bucket.

https://stackoverflow.com/questions/2923272/how-to-convert-v...

Mixing high level C++ stdlib classes with low level C APIs is often not exactly trivial, for instance most C++ containers expect that their items are RAII compatibel, and the resulting memory corruption errors will be harder to debug than plain old C code because the shit hits the fan deep inside some completely unreadable C++ stdlib implementation code.

Yes, but if you're writing code that you want to be bindable to other languages, you essentially have to follow the C ABI, in which case, writing in C is a natural choice (yes, you can expose a C ABI from other languages, but that's usually not natural and you sort of have to understand C anyway to do that).

Unless your API surface constitutes the majority of your code, writing in C still doesn't make sense, because you're paying the tax every time you have to manually juggle strings and whatnot. C++ is a more sensible choice for this - you can still write C-compatible headers (and it's trivial to verify in builds - just include it in a .c file and see if that compiles!) while using STL etc in the implementation.

Yeah if you're using opaque handles (where what you have is really a pointer to some C++ thing), this can work well.

If you're exposing structs that are passed back and forth for state, it's a bit more cumbersome.

D code can call C functions directly.

C + a set of macros is a more powerful programming language.

Also a far worse language though. Macros have their place, but trying to do anything complex with them just turns into a total nightmare. They're hard to reason about, walk through, or modify.

If heavy macro usage is found, it's definitely time to reconsider the approach.

It really depends on how macros are used. If you're just using them to implement "high level language features", it's not a problem; sure, you might have trouble figuring out what STAILQ_INSERT_TAIL does internally, but you're going to have just as much trouble figuring out what the Lisp or Perl or Python "add this item to the end of that list" operations do internally.

Macros can be a nightmare, but when they're used properly they're not.

> when they're used properly they're not

Yeah, they are.

Source: Decades of C programming

You're not the only person with decades of experience.

We all suffer from this, so it's not personal, but one is too often blind to the shortcomings of one's own code.

You must be aware that I'm not the author of BSD sys/queue.h.

If were me I'd use inline functions instead of macro's

C is powerful enough.

Lisp?

Yes! :-)

When it comes to macros, accept no substitute.

Granted, Lisp already has arrays, so not much reason to reinvent the wheel.

  (make-array '(2 6) :initial-element 0 :element-type '(unsigned-byte 32))
  ;; => #2A((0 0 0 0 0 0) (0 0 0 0 0 0))

Yeah that's a great opinion and all but generally C is used because it HAS to be used these days. No one is going to use this code for building a web application or will be tossing it into legacy code.

Reply on news.ycombinator.com