C++ Logo

std-proposals

Advanced search

Fwd: Message privé sur le sujet suivant : Thought on Standard API for C++ Implementations

From: Andrew Tomazos <andrewtomazos_at_[hidden]>
Date: Sun, 29 Dec 2019 02:40:58 +1000
---------- Forwarded message ---------
From: Olivier Sohn <olivier.sohn_at_[hidden]>
Date: Sat, Dec 28, 2019 at 10:55 PM
Subject: Message privé sur le sujet suivant : Thought on Standard API for
C++ Implementations
To: <andrewtomazos_at_[hidden]>


Hi,

I think the mailing list has changed:

https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/C-jBaB00QaE

But regarding the content of the proposal, I like the idea. I was thinking
of these 2 aspects:

1. Standardization of compilation / link options

Do you want to attempt to standardize some of them, or not (i.e represent
them as a vector<string>) ?

2. Inputs / Outputs streams

In the API, inputs and outputs are files but to be more general we could
represent them as streams (for JIT use cases for example).

This would allow to dynamically compile code that is not in a file, to a
program that is not in a file either.

Regards,

Olivier



Le vendredi 27 décembre 2019 07:15:42 UTC+1, Andrew Tomazos a écrit :
>
> 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?
>
>

Received on 2019-12-28 10:43:40