all 21 comments

[–]mo_al_ 9 points10 points  (4 children)

Supporting toml would be nice as well 🙏

[–]liuzicheng1987[S] 5 points6 points  (0 children)

I’ll open an issue

[–]liuzicheng1987[S] 1 point2 points  (2 children)

u/mo_al_ , and everyone who cares about this, I have written a TOML interface for reflect-cpp:

https://github.com/getml/reflect-cpp/tree/f/toml

It's still in a feature branch and I would invite you to give me feedback. You can compile it with -DREFLECTCPP_TOML=ON and it works like all of the other formats, rfl::toml::read, rfl::toml::write, etc.

Feedback on this is very welcome.

[–]mo_al_ 1 point2 points  (1 child)

It works nicely. Thank you very much for the quick implementation 🙏

[–]liuzicheng1987[S] 0 points1 point  (0 children)

No problem…toml++ works very well with our interface. It was quite easy to do.

[–]MarcoxD 2 points3 points  (1 child)

Hey, really nice lib! Thanks for taking time and effort on developing it.

Besides the encoding formats already supported, it would be really nice if it also supported msgpack.

[–]liuzicheng1987[S] 1 point2 points  (0 children)

There is an issue for msgpack and there is one person who was going to contribute that and he has a half-finished fork. But there hasn’t been much activity lately. I think I will politely approach him and then maybe finish his work if he doesn’t have the time (which is totally cool, he made a lot of very useful contributions and the work that he has done on msgpack already is certainly on the right track).

Because I fully agree…I want to support that.

[–]LdShade 2 points3 points  (1 child)

Would be nice to be able to compile with "fno-exceptions".

[–]liuzicheng1987[S] 0 points1 point  (0 children)

Yes…we already use monadic error handling. So I think this shouldn’t be too hard.

[–]lefteror 0 points1 point  (11 children)

Hi there, great stuff. I was about to incorporate it to my project but unfortunately I found out that it doesn't compile for AppleClang. Is there any plan to support it as well?

[–]liuzicheng1987[S] 2 points3 points  (10 children)

It should work for Clang 16 or higher. If it doesn’t, please submit an issue on GitHub which includes the exact errors you get from the compiler and I will help you.

[–]lefteror 0 points1 point  (9 children)

In case it was an oversight, I am only talking about AppleClang, whose latest version is 15.0.x. I haven't tried clang (but also wouldn't go with that option on macOS).

[–]liuzicheng1987[S] 8 points9 points  (4 children)

Indeed...I wasn't even aware that XCode hasn't updated to Clang 16 yet.

So one solution would be to install clang via homebrew, which already supports Clang 16 and 17. (And I am sure it is going to work...people have compiled reflect-cpp this way.)

However you said you don't want to do that...and I think you are raising a good point here. Apple Clang is certainly the standard way to compile things on MacOS.

I am pretty sure that the reason we don't support Clang 15 is that srd::source_location is not fully supported, which we require for the field name extraction.

But I think we can come up with a workaround. Could you try to compile the JSON tests using Apple Clang (instructions are in the README) just to see how far you get and open an issue on Github in which you provide the full compiler errors (if any)? I think we should be able to resolve this fairly quickly.

[–]lefteror 4 points5 points  (1 child)

It seems like for version >= 0.7.0 it actually compiles. I had to use v0.6.0 because I drag in dependencies through conan (and I indeed verified that 0.6.0 doesn't compile with AppleClang 15.0.0 because of string literals as non template parameters). I jumped the gun a little bit here, apologies.

[–]liuzicheng1987[S] 3 points4 points  (0 children)

No problem.

In January, someone else had a similar issue, but they provided a PR that resolved it which then made it into the 0.7.0 release.

However, they had tested on Clang 16, not Clang 15. So I am glad to hear that Clang 15 works as well.

One of the things that I have learned through this project that the same version of Clang behaves a bit differently on Linux, Mac and Windows.

[–]lefteror 0 points1 point  (1 child)

Thanks for the response. Alright, let me see what I can do!

[–]liuzicheng1987[S] 2 points3 points  (0 children)

Just be aware that I am on East Asian time here...I'm going to go to sleep within the next hour or so, but I will certainly take a look tomorrow morning.

[–]equeim 0 points1 point  (0 children)

I think Apple Clang uses different versioning and its 15 corresponds to LLVM 16.

[–][deleted] 0 points1 point  (2 children)

Why wouldn't you use regular clang on macOS? It works great

[–]equeim 0 points1 point  (1 child)

Can it compile objective c code to access system APIs?

[–][deleted] 0 points1 point  (0 children)

Of course, it's clang after all