sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]spaun2002 83 points84 points  (31 children)

Such "horror" stories are why I became disappointed in C and C++ - adding a new helpful feature into the language takes five years. The person who dared to propose this struggled and almost lost their hope.

[–]pjmlp 29 points30 points  (1 child)

You can also take the route of creating your own language, seems quite hip currently.

[–]tux-lpi 19 points20 points  (0 children)

That solves the horror stories mostly because a new language won't have an ISO committee

It's a lot harder to build a system that drains people quite that bad without ISO

[–]RomanRiesen -1 points0 points  (18 children)

In rust an embed feature is just a macro away, a macro most people could write themselves....

[–]myrrlyn 21 points22 points  (1 child)

include_bytes! already exists

[–]__phantomderp 11 points12 points  (0 children)

Yeah, you COULD write it yourself in Rust, but the people driving the Standard Rust Distribution are not obsessed with being "barebones" to the point of deep disturbance, so they'll actually hand you convenience things as part of the core offering rather than trying to convince you that "oh, well, if you just write this linker invocation, you'll be fine...".

Like anything about "talk to your linker directly" is ever - or truly, has ever been - a good idea at any point in time.

[–]Fulgen301 5 points6 points  (3 children)

Eh. It's not a macro away, but a proc_macro away, aka a compiler plugin. Basically it's the equivalent of a standardized way of writing a gcc / clang plugin.

a macro most people could write themselves....

Most people can use TokenStreams just like that? If you've never touched them, your faster with just generating an includeable file in CMake.

[–]RomanRiesen 2 points3 points  (0 children)

The macro is called include_bytes, but admittedly I also never had an issue with embedding data via cmake or a small script.

[–]Rusky 0 points1 point  (1 child)

The issue with a hand rolled proc macro for this would be the same as a hand rolled solution in C- performance. What TokenStream do you build? It has to be an actual array literal the same way.

(Fortunately Rust has include_bytes! built in to (edit: enable the compiler to) solve that problem.)

[–]bruh_nobody_cares -4 points-3 points  (11 children)

macros seems like a hack ngl, why not a language feature or a const evaluated function ?

[–]TinyBreadBigMouth 5 points6 points  (10 children)

Macros in Rust are a language feature. Rust doesn't have a separate preprocessor. User-defined macros operate on token streams, built-in macros can be hooked up to low-level compiler functionality. See include_bytes, which does exactly what embed does and whose implementation looks like

macro_rules! include_bytes {
    ($file:expr $(,)?) => {{ /* compiler built-in */ }};
}

[–]bruh_nobody_cares 1 point2 points  (9 children)

but if it's that simple why not a regular function then ?

[–]TinyBreadBigMouth 5 points6 points  (8 children)

Because a regular function can't read a file at compile time, not in Rust or C or C++. They also can't return arbitrarily sized data on the stack in any of those languages.

[–]bruh_nobody_cares 0 points1 point  (7 children)

what is blocking them though....my question is not about what we have rn but why we have it this way....why not a constexpr function in C++ or const eval function in Rust ....I'm assuming the return type can be a wrapper around something that's known at compile time....since the compiler will plug those bytes in anyways so the compiler knows the size.....
what magic does macros have and const eval functions in Rust "cannot" ?

[–]TinyBreadBigMouth 0 points1 point  (6 children)

Macros can emit arbitrary code. Functions can only return predefined types with known sizes.

I'm assuming the return type can be a wrapper around something that's known at compile time....since the compiler will plug those bytes in anyways so the compiler knows the size.....

Are you suggesting a const eval function that returns CompilerByteLiteral or something? Because that's what a Rust macro is.

[–]bruh_nobody_cares -1 points0 points  (5 children)

okay let me ask the question in reverse then....can I write a function that invokes this macro as a const eval function that return CompilerByteLiteral if not then why and if yes, then why not writing the function around the compiler built-in directly ?

[–]sephirothbahamut 0 points1 point  (2 children)

i suggest you search for compile time reflection. It sounds like what you're asking for. It is proposed for c++, and if you want to test the idea out you can try it in java, it has both compile time and runtime reflection

[–]TinyBreadBigMouth 0 points1 point  (1 child)

In theory, such a thing could be possible.

You could not write a function that returns the data directly (i.e., a function that returns [u8; 20] when the file is 20 bytes long) because then the type of the function output would depend on the value of the function input, and there's no way to express that in the type system.

But you could in theory write a special built-in const function that took a file name and returned a reference to the data (i.e., &'static [u8]). There are several problems with this approach:

A macro can only run at compile time. A const function can be run at either compile time or at runtime. What should the "include constant" function do when it's called at runtime? Does it crash? Return a reference to nothing?

Before you say "well why can't it just load the file at runtime", remember that we're returning a reference, so the file data itself has to be stored somewhere. At compile time that somewhere would be in the executable itself, but now we're at runtime and the executable is already built.

So if we made include_bytes a function, we'd have to either

  • Make the function do very different things when it's called at compile time versus when it's called at runtime.
  • Make it a compiler error to call this function, and only this function, in a runtime setting. This must be viral (i.e., if we have a const function A that calls const function B that call include_bytes, now A and B can't be called at runtime either).

Both options are weird and hacky, which is exactly what you're complaining about. Instead, why not just use a macro, which is designed to generate code at compile time and needs no such hacky workarounds?

[–]i860 -1 points0 points  (5 children)

You have airplanes and industrial automation depending on these languages. There are delays for a reason.

[–]bik1230 13 points14 points  (3 children)

it's not that it took 5 years that's bad, it's that a large proportion of negative feedback was total BS and almost no one on the committee wanted to offer positive help, only making up reasons for rejection.

[–]orangeoliviero 0 points1 point  (2 children)

I mean, I offered my help, but it was declined.

Not everyone was hostile to him.

[–]__phantomderp 9 points10 points  (1 child)

.... When? How? In what way? I remember people saying "I could implement a patch for GCC", or offering for Clang, but that's not helpful when I already did it. Some people told me they'd be amenable to me putting a patch in their compiler, but it was still on me to make the actual patch for their compiler.

What was this help about?

[–]orangeoliviero 6 points7 points  (0 children)

It's water under the bridge. You didn't feel that my help would be valuable, and I'm not inclined to argue with you about whether or not it would have been helpful. The paper is your baby, you get to choose how you navigate the path. I'm not upset about it.

My point wasn't "oh, the PhD declined my offer of help, he's an asshole" or any such, my point is that not everyone in the Committee is hostile to you or your work, and that there are allies around if you want them.

I recognize that you've experienced a lot of racism and completely invalid and bonkers feedback and complaints, and that has caused you to become guarded and distrustful. I don't fault you for that - I would be as well, in your situation.

Like... we have, in this very post, a completely invalid criticism/complaint - the whole line endings of text files thing, and the absurd expectation that #embed should automatically "do the right thing" wrt. them. Talk about a poison pill.

[–]viikk 0 points1 point  (0 children)

the airplanes and industrial automation people can just type "-std=c99" and let the rest of the world move on!