Ah yes, we've come full "circle" and C++ has tacked on D's metaprogramming and CTFE abilities.
[deleted]
Circle: C++ Automation Language
11–20 of 27 posts
Re: Circle: C++ Automation Language
#12Why are the examples in C code rather idiomatic Modern C++?
Re: Circle: C++ Automation Language
#13This seems useful for code generation. Cannot relate this to any previous problems I encountered using c++ Any other interesting use of this?
Seems that it could be used to solve an old-time classic: generate a mapping from an enum value to its string representation. Another use case that comes to my mind is maybe automating test case generation. Occasionally I was running into situations where I thought code generation could be useful, but not sure what could be a "killer app" equivalent for this feature. Related topic: standardizing reflection in c++. ht…
Enum to string is a one-line expression in Circle:
https://godbolt.org/z/93f5o77zv
Circle has dozens of special traits for accessing useful stuff about types, packs, etc. Don't need to overengineer such a simple thing.
Re: Circle: C++ Automation Language
#14This is really neat. I've done similar things with jinja templates plus heavy use of c++ template magic - with the downside that there's a bit of disconnect between the two syntaxes. I'll have to keep an eye on this for the future.
Re: Circle: C++ Automation Language
#15This seems useful for code generation. Cannot relate this to any previous problems I encountered using c++ Any other interesting use of this?
My favorite use is putting user-defined attributes on data members, and using reflection to generate a UI to manipulate those values. I do it with these shadertoys:
https://github.com/seanbaxter/shaders#reflection-and-attribu...
Just mark your declarations up with custom attributes:
[[.imgui::range_float { .1, 5 }]] float Zoom = 1.5;
[[.imgui::range_float { 0, 1 }]] float Speed = .15;
[[.imgui::range_float { .1, 1 }]] float XScale = .3;
[[.imgui::range_float { 0, .5 }]] float YScale = .2;
The kind of data you reflect over will likely come from within the program.
Re: Circle: C++ Automation Language
#16This project feels similar in spirit to Zig, which has robust compile time evaluation and reflection. The cool part about Zig is that it uses this ability (via the `comptime` keyword) to power it’s generic system, and not vice versa (looking at you, Turing complete type systems) https://ziglang.org/learn/overview/#generic-data-structures-...
Truly the Lisp-equivalent of static evaluation. So probably won’t catch on (too ad hoc, not very declarative, not exhaustive).
At least they give it a nice abbreviation like “comptime” instead of the atrocious “CTFE” that C++ seems to like.
Re: Circle: C++ Automation Language
#17This seems useful for code generation. Cannot relate this to any previous problems I encountered using c++ Any other interesting use of this?
Imagine you want to intern your printf strings somewhere so that your logs look like logit(“some message providing more details. %s, %d”, someStringArg, someIntArg). Typically you have to serialize the whole thing and store it. However, if you save the compile string into a separate database at compile time and the call site transforms to logit(msgId, someStringArg, someIntArg), then you’ve reduced your logging cost to the cost of serializing the log message which is drastically cheaper, faster and takes less space in whatever log storage system you use. You only pay the formatting cost when you go to display the logs to a person.
Re: Circle: C++ Automation Language
#18This seems useful for code generation. Cannot relate this to any previous problems I encountered using c++ Any other interesting use of this?
Seems that it could be used to solve an old-time classic: generate a mapping from an enum value to its string representation. Another use case that comes to my mind is maybe automating test case generation. Occasionally I was running into situations where I thought code generation could be useful, but not sure what could be a "killer app" equivalent for this feature. Related topic: standardizing reflection in c++. ht…
There is also this approach - https://github.com/Neargye/magic_enum
the trick (relyiong __FUNCTION__ like macros/(funcs?)) is here - https://github.com/Neargye/magic_enum/blob/master/include/ma...
and https://github.com/Neargye/magic_enum/blob/master/include/ma...
Re: Circle: C++ Automation Language
#19This seems useful for code generation. Cannot relate this to any previous problems I encountered using c++ Any other interesting use of this?
My favorite use is putting user-defined attributes on data members, and using reflection to generate a UI to manipulate those values. I do it with these shadertoys: https://github.com/seanbaxter/shaders#reflection-and-attribu... Just mark your declarations up with custom attributes: [[.imgui::range_float { .1, 5 }]] float Zoom = 1.5; [[.imgui::range_float { 0, 1 }]] float Speed = .15; [[.imgui::range_float { .1, 1 }]…
Nice! This is definitely my main usecase for reflecty things lately, along with serialization for the data (game engine scenarios). I've been doing static reflection + attributes through this: https://godbolt.org/z/enh8za4ja Which actually comes out to a not-so-bad syntax and the attributes can be read constexpr (some limitations though: simple aggregate-y structs, and all reflected fieds must appear before non-reflected ones).
Lately I've been working on a Go (pretty small subset -- no GC or concurrency) to C++ compiler and generating meta stuff as part of it. Mostly because I like how focused Go's syntax is and also it having an official parser and type checker in the standard library makes things pretty quick to get started.
I should play with Circle some time! It's definitely touching on a lot of the desired things from a metaprogramming layer.
Re: Circle: C++ Automation Language
#20I like circle, and Sean does a lot of great work, but I'll have to stick to more pedestrian code generation for now.
It might seem too picky to some, but I need to have good control over the inputs into my build processes. There are the obvious concerns regarding reproducibility and security which, again, maybe some don't care about. But there are also implications for distributed building and caching workflows. Circle doesn't practically drop in for C++ while it is allowed to do arbitrary I/O (even off the machine!) at build time.
It seems like it should be a solvable problem at the expense of restricting what can happen at compile time, at least as an opt-in feature.
The usual response is "well, don't do that kind of thing!", but at scale, manually maintaining that kind of design standard isn't practical. But I'm sure you all audit all the source that feeds into each one of your container base images.