Re: New library: argparse, for parsing CLI arguments
On Thursday, 14 October 2021 at 15:03:34 UTC, Steven Schveighoffer wrote: Having done a lot of stuff with serialization and UDAs, this turns into a mess if you have multiple systems (serialization is really what you are doing here) using the same structs. So really, you are likely to have this `Params` struct be distinctly for parameter parsing. It's OK to have requirements such as expecting all items to be serialized by default and in a default way. Structs without UDA are now supported starting version `0.4.0`. I also added this use case as a basic into "Getting started" section in readme.
Re: Beta 2.098.0
On Sunday, 17 October 2021 at 17:55:05 UTC, Adam D Ruppe wrote: On Sunday, 17 October 2021 at 17:09:40 UTC, Guillaume Piolat wrote: Doing it by hand, until now, has been the preffered way to translate C and C++ headers. Why did dstep fail for them? How would importC help the bindBC project? I think this is actually an issue with process rather than technology. The ideal way to do bindings, in my opinion, is to rigorous lock in to / check-in a certain header file, then generate the bindings at build time. ImportC might make that less of a hassle but fundamentally I think the abstraction wrong at the moment.
Re: Beta 2.098.0
On Sunday, 17 October 2021 at 17:09:40 UTC, Guillaume Piolat wrote: Doing it by hand, until now, has been the preffered way to translate C and C++ headers. Why did dstep fail for them? How would importC help the bindBC project?
Re: Beta 2.098.0
On Sunday, 17 October 2021 at 15:54:46 UTC, Dennis wrote: On Tuesday, 12 October 2021 at 12:55:16 UTC, Adam Ruppe wrote: On Sunday, 10 October 2021 at 23:11:56 UTC, Walter Bright wrote: ImportC resolves a long standing serious issue where multiple other substantial attempts at solving it have fallen short over the years. Why have the other approaches fallen short? How does importC address these problems? A bit late, but I really want to make [a reference](https://xkcd.com/927/). Situation: There are 4 competing tools/approaches for interfacing with C .h files. Walter: 4?! Ridiculous! We need to develop one universal tool that covers everyone's use cases. [Soon] Situation: There are 5 competing tools/approaches. I kinda agree here. Although all tools are splendid in their own way, the ultimate solution would be some kind of hybrid.
Re: Beta 2.098.0
On Tuesday, 12 October 2021 at 12:55:16 UTC, Adam Ruppe wrote: On Sunday, 10 October 2021 at 23:11:56 UTC, Walter Bright wrote: ImportC resolves a long standing serious issue where multiple other substantial attempts at solving it have fallen short over the years. Why have the other approaches fallen short? How does importC address these problems? One of D's ecosystem most valuable set of libraries (BindBC formerly Derelict) are exactly that: translation of C headers by hand. Doing it by hand, until now, has been the preffered way to translate C and C++ headers.
Re: Beta 2.098.0
On Tuesday, 12 October 2021 at 12:55:16 UTC, Adam Ruppe wrote: On Sunday, 10 October 2021 at 23:11:56 UTC, Walter Bright wrote: ImportC resolves a long standing serious issue where multiple other substantial attempts at solving it have fallen short over the years. Why have the other approaches fallen short? How does importC address these problems? A bit late, but I really want to make [a reference](https://xkcd.com/927/). Situation: There are 4 competing tools/approaches for interfacing with C .h files. Walter: 4?! Ridiculous! We need to develop one universal tool that covers everyone's use cases. [Soon] Situation: There are 5 competing tools/approaches.
