Date: Mon, 17 Sep 2018 17:36:59 -0500
On Mon, Sep 17, 2018 at 5:04 PM JF Bastien <cxx_at_[hidden]> wrote:
> On Mon, Sep 17, 2018 at 1:38 PM Rene Rivera <grafikrobot_at_[hidden]> wrote:
>
>> On Mon, Sep 17, 2018 at 3:31 PM Tony V E <tvaneerd_at_[hidden]> wrote:
>>
>>> Also, if you give me a function called std::compile(), that compiles
>>> code, it seems I can now write a compiler?
>>>
>>> int main(int argc, char ** argv)
>>> {
>>> return std::compile(argc, argv);
>>> }
>>>
>>> Wow, that was easy.
>>> Can the paper explain what I'm misunderstanding? (Or maybe it does
>>> explain, but I missed it)
>>>
>>
>> That's a correct understanding. And that's the one example I use in my
>> implementation <
>> https://github.com/bfgroup/std_cpp/blob/master/example/std_cpp.cpp>. I
>> do try and explain the goals in the paper. In that it serves a dual
>> purpose. But mainly it's a way to standardize the compiler options.
>>
>
> Right, otherwise you'd have to do:
>
>
> int main(int argc, char** argv) {
> std::system((std::string("clang ") + argv[1]).c_str());
> return 0;
> }
>
>
> ;-)
>
> More seriously, the selection of compiler options you've chosen seem
> semi-random.
>
First it's not random :-) It's the minimal to get basic actual compiling
working and to show highlight some of the differences in link
compatibility. Second, it's very incomplete. I'll keep adding options as I
implement them from now until the mailing deadline (and keep implementing
them afterwards for an R1 paper -- and so on). Third, I hope I can get some
volunteers to help in adding options.
> It would be useful to have a survey of existing compilers and their
> options, and some criteria to determine which should be supported here and
> which shouldn't.
>
Selection criteria is indeed a hard problem. What's actually needed for
core? And what can be delegated to the vendor specific realm?
Further, what's the expectation of the result of calling this function? Can
> I actually execute any code? How? Can you make sure that you take into
> account the restrictions various platforms have, such as requiring code
> authentication. It goes way beyond linkers.
>
The proposal doesn't, intentionally, say anything about executing code.
This is one of those "implementation defined" areas. Just like it is
currently in the standard. If it's possible to execute code in some manner,
either indirectly through an std::system equivalent or directly through
JIT/DLL, is left for the implementor/compiler to document.
> system seems like a precedent for what you suggest, and in my experience
> system isn't a precedent people want us to repeat.
>
"std::system" is what the sample implementation uses.. but it's possible
you could implement it as a direct library call (easily doable for Clang,
for example). And ideally production implementations would use something
more robust than std::system ;-)
> On Mon, Sep 17, 2018 at 1:38 PM Rene Rivera <grafikrobot_at_[hidden]> wrote:
>
>> On Mon, Sep 17, 2018 at 3:31 PM Tony V E <tvaneerd_at_[hidden]> wrote:
>>
>>> Also, if you give me a function called std::compile(), that compiles
>>> code, it seems I can now write a compiler?
>>>
>>> int main(int argc, char ** argv)
>>> {
>>> return std::compile(argc, argv);
>>> }
>>>
>>> Wow, that was easy.
>>> Can the paper explain what I'm misunderstanding? (Or maybe it does
>>> explain, but I missed it)
>>>
>>
>> That's a correct understanding. And that's the one example I use in my
>> implementation <
>> https://github.com/bfgroup/std_cpp/blob/master/example/std_cpp.cpp>. I
>> do try and explain the goals in the paper. In that it serves a dual
>> purpose. But mainly it's a way to standardize the compiler options.
>>
>
> Right, otherwise you'd have to do:
>
>
> int main(int argc, char** argv) {
> std::system((std::string("clang ") + argv[1]).c_str());
> return 0;
> }
>
>
> ;-)
>
> More seriously, the selection of compiler options you've chosen seem
> semi-random.
>
First it's not random :-) It's the minimal to get basic actual compiling
working and to show highlight some of the differences in link
compatibility. Second, it's very incomplete. I'll keep adding options as I
implement them from now until the mailing deadline (and keep implementing
them afterwards for an R1 paper -- and so on). Third, I hope I can get some
volunteers to help in adding options.
> It would be useful to have a survey of existing compilers and their
> options, and some criteria to determine which should be supported here and
> which shouldn't.
>
Selection criteria is indeed a hard problem. What's actually needed for
core? And what can be delegated to the vendor specific realm?
Further, what's the expectation of the result of calling this function? Can
> I actually execute any code? How? Can you make sure that you take into
> account the restrictions various platforms have, such as requiring code
> authentication. It goes way beyond linkers.
>
The proposal doesn't, intentionally, say anything about executing code.
This is one of those "implementation defined" areas. Just like it is
currently in the standard. If it's possible to execute code in some manner,
either indirectly through an std::system equivalent or directly through
JIT/DLL, is left for the implementor/compiler to document.
> system seems like a precedent for what you suggest, and in my experience
> system isn't a precedent people want us to repeat.
>
"std::system" is what the sample implementation uses.. but it's possible
you could implement it as a direct library call (easily doable for Clang,
for example). And ideally production implementations would use something
more robust than std::system ;-)
-- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net
Received on 2018-09-18 00:37:12