Thought on Standard API for C++ Implementations

[Andrew Tomazos]

There are a number of fundamental use cases of C++ implementations, such as:

- compiling a C++ source file into an object file

- linking object files into a static library

- linking object files into a dynamic library

- linking object files, static libraries and dynamic libraries into programs

- coming soon: do stuff with modules

Each of these has a plethora of complex options.

I see two problems with the status quo:

- Each implementation has a different syntax for expressing the input, output and options of each of these use cases.

- The options are expressed through the command-line, which, as a data model, is essentially a dumb std::vector<std::string> with some kind of embedded implementation-specific DSL.  Some of the rules around that DSL are downright insane.  The result is expressed through an int exit code and semi-structured text with a non-standard format on STDERR.

For a taste of this look at:

   https://docs.conan.io/en/1.21/reference/generators/compiler_args.html

I've been wondering whether it would be at all interesting if we proposed a standard API for implementations.  Perhaps this could even be a C++ API.

As a quick scribble, along the lines of:

    namespace std {

        compilation_result compile_source_file(

            const filesystem::path& output_object_file,

            const filesystem::path& source_file,

            const vector<filesystem::path>& include_paths,

            const map<string, string>& defines,

            etc

        );

 

        linking_result link_program( etc );

        ...other types / functions

     }

The idea here is that the parameters and return type of each function are strongly typed, standardized, with well-specified semantics (like a normal API).  People building atop them only have to write the client code once, and it will work across all standard implementations and platforms.  The interface would also be far more robust (less error-prone) than the CLI DSL and "error scanners".

Thoughts?

[Richard Hodges]

Yes, yes. A thousand times yes.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHJq3cAkcQtsdpZA3ouu6_yFqOdpLq6JwedfvKuN7EBDiA%40mail.gmail.com.

--

Richard Hodges

hodg...@gmail.com

office: +442032898513

home: +376841522

mobile: +376380212

[Klaim - Joël Lamotte]

On Fri, 27 Dec 2019 at 07:15, Andrew Tomazos <andrew...@gmail.com> wrote:

I've been wondering whether it would be at all interesting if we proposed a standard API for implementations.  Perhaps this could even be a C++ API.

As a quick scribble, along the lines of:

    namespace std {

        compilation_result compile_source_file(

            const filesystem::path& output_object_file,

            const filesystem::path& source_file,

            const vector<filesystem::path>& include_paths,

            const map<string, string>& defines,

            etc

        );

 

        linking_result link_program( etc );

        ...other types / functions

     }

The idea here is that the parameters and return type of each function are strongly typed, standardized, with well-specified semantics (like a normal API).  People building atop them only have to write the client code once, and it will work across all standard implementations and platforms.  The interface would also be far more robust (less error-prone) than the CLI DSL and "error scanners".

Thoughts?

  There was a proposal about running a compilation but the arguments were the usual table of strings.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1178r0.html 

Maybe your idea could be an evolution of that proposal?

 

[Andrew Tomazos]

Thanks, yes, Rene has been in touch.