220 41242 <9f2c63e2-7904-49ea-a2ac-87e80fe78e78@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: masse.nicolas@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Modules and preambule, just why? Date: Tue, 11 Dec 2018 14:06:30 -0800 (PST) Lines: 224 Approved: news@gmane.org Message-ID: <9f2c63e2-7904-49ea-a2ac-87e80fe78e78@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_81_1128770004.1544565990604" X-Trace: blaine.gmane.org 1544565867 14402 195.159.176.226 (11 Dec 2018 22:04:27 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 11 Dec 2018 22:04:27 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCCJBHV4UALBBZ7JYDQAKGQECVUSRDQ@isocpp.org Tue Dec 11 23:04:23 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb1-f200.google.com ([209.85.219.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gWq8c-0003fW-QG for gclcip-std-proposals@m.gmane.org; Tue, 11 Dec 2018 23:04:23 +0100 Original-Received: by mail-yb1-f200.google.com with SMTP id s7-v6sf10639897ybp.10 for ; Tue, 11 Dec 2018 14:06:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=s19GC45A2O/rhjDTxHkSOhDNYbuI8k6vEChYniyW+VQ=; b=XjmME9L+WigQ8eRC4UOjG5UWUvt/4hmiIMkNxEXOCBEJ+CktPn06z+ShDoNSjNvv/c jgvOWSBjhfrc7KXLcheJdCQ28cCfK0DxYvkTlUhvQqKNsaNckD92KB0mArMGOgwo5fvC LNemyyNdvzkkyMqwQc+V+3gG7O/VcwARA24H8xXOwLj7CyBvF+HWNDVnWL7lP7w/jm4q tffRisF8RlwZZb+lny0vQa6b1TSAxmRDhpUACx3D1A/vpHGMr+gBtCuTATOcnHMjSREN aQeo4ZpCIEm6blPowfggqyq3tR0BNtnYKeX/p50chaeSVSkEOF231apD+/uh//6xN8W2 wpTQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=s19GC45A2O/rhjDTxHkSOhDNYbuI8k6vEChYniyW+VQ=; b=NZPRAUym0QsdPT4Dv0yFITsgRSkYwJJ/TQmoqemNX8kCTcJqyXqfUoeBtQt6F3t6Zy Fu23KtinLHDxhuLVYNQKTYHIYV+lKsqIf5S1qfjL6cWE+PqdO3J4eVp6TR+9CqVb7jFl va3DCTMq7L2l8BuayJ/0ltxgaSO28PcN8f4pqK8TniQn4nxt+ms5sIkGTBuD12L0Czuz bzifddX9bFE6QTxPDARl/kNUlumNVQBNZY5iqtTzxXcb1TGyvehl92iCNKkzM9j0aAuX 9+IBp+pvANLvjyf50z7acbeWJoSxbjjH9QJxxhchNlF91ZQlc4EfOQlxXw0Ls92pwGOu 2u1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=s19GC45A2O/rhjDTxHkSOhDNYbuI8k6vEChYniyW+VQ=; b=Nh7QNB82nX+BK20WwjVVr35YIl/vyObUIKVEz1VkMZQxurPe5xTqHrACYDP2O+BT2W glS9KxrSSiLD5dZ3eCuHgiLONN29BhsKGXeALEnaLLOqrQQZAq0WtPMFRXyyTAZpDGVA 74VWbkryukcwzI5HMu/e+rmwyqccv0KjRcHuprf91plSNgPQe429WDvsh302e39dJAfV w3ZY+9SDcD8nFIfvZMlrSaksSsBgEJ7x2cdrHx4GLGB+w20Tpt3PlGQMtfg3pMiZ/Z5y /chpShe/RO8mdns2ycUA61/NGgiNKzn4KmfJ9mWF9wRA3qNqSv4T67LmOPkosxGon38f n/1Q== X-Gm-Message-State: AA+aEWZfX8jeicY61SX7QcGQMwoSt8wT2+gC+FtrfB3a2987qfxYw1wj lyVuHepT5CwdGs1ZAVF5Ol/+iA== X-Google-Smtp-Source: AFSGD/W1J48vzUsxdQrZGrO1I+eev9PXIpzTIHVKWc10IGChv0CSa+vLMK7cCFvkdTIRUg/ykeKR0w== X-Received: by 2002:a25:ef47:: with SMTP id w7-v6mr10068024ybm.58.1544565992959; Tue, 11 Dec 2018 14:06:32 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:3515:: with SMTP id c21ls8298644ywa.8.gmail; Tue, 11 Dec 2018 14:06:31 -0800 (PST) X-Received: by 2002:a81:115:: with SMTP id 21mr286430ywb.7.1544565991315; Tue, 11 Dec 2018 14:06:31 -0800 (PST) In-Reply-To: X-Original-Sender: Masse.Nicolas@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:41242 Archived-At: ------=_Part_81_1128770004.1544565990604 Content-Type: multipart/alternative; boundary="----=_Part_82_2139354162.1544565990604" ------=_Part_82_2139354162.1544565990604 Content-Type: text/plain; charset="UTF-8" > I meant that, if you are shipping a pre-built library, then the portions > of the module interface unit that are not "interface" (e.g., > non-template function definitions) probably need to be pre-compiled and > linked into the distributed library (which may have its own dependencies > on them) unless the expectation is that the recipient link objects > produced by compilation of module interface units into their respective > binaries (which seems to me a good recipe for ending up with duplicate > definition errors at link time). I'm very curious to see how build > systems are going to end up managing this. > So you have the choice whether you ship the source files or a binary version of it. OK. Deduced how? > Take this code for example: //sample.cpp namespace sample { struct event { std::string message; std::string details; std::string file; uint line; }; class event_printer { using format_fn = std::function; std::vector m_functions; public: event_printer(const std::string& format); std::string format(const event& ev) const { std::string res; for(const auto& fn : m_functions) fn(res, ev); return res; } }; } From this code, you can easily say that importing this file will import the declaration of the 2 structs, the first one being just a POD data type, while the second will have a ctor from a std::string and also a method format with the given signature. Note that in this example, the implementation of the ctor and the format method could be in the same cpp file but don't require to, since the declaration of the class is enough. The problem we have today with headers is that everything > in a header needs to be parsed, whether part of the actual > interface of the library or not. > The idea here is to parse the file only once and to save the "visible" part of it in a specific file. The next time this file will be imported, we could just extract the visible part from the generated file (since the source file didn't change since the other one was generated), avoiding then to re-parse the source. Modules give us control over what > things are part of the interface and what things are not. > Yeah, something in my approach is more or less missing here. More or less I said? Yes, because in fact this partially already exists. I mean, take this code for example: //sample_details.cpp static void print_message(std::string& msg, const event& ev) { msg.append(ev.message); } Here you know that the method print_message won't be exported by the compiler, and thus non-visible outside of the sample_details.cpp file. Even if you import this file (which shouldn't be done if we take the logic of my example into account), this method won't be imported because it is internal to the sample_details.cpp file. In fact, this mechanism is inherited from C, meaning that it exists from a long time. But unfortunately, it use the static keyword, which could have different meanings when used inside a class. Perhaps deprecating the use of static in this context and replacing it by something else (say internal for example) could do the trick. So i just give you a small example of how I saw things, but there are probably a lot of related problems which need to be resolved, for example how template should be handled when using this model. I didn't try to solve all this since my goal is just to make you understand what I mean by "an approach where the exported symbols are deduced from the code". Also I believe that most of the choice made for the module proposal could apply to this model as well. Masse Nicolas. -- 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-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9f2c63e2-7904-49ea-a2ac-87e80fe78e78%40isocpp.org. ------=_Part_82_2139354162.1544565990604 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I meant that, if you are shipping a pre-built library, then the portion= s=20
of the module interface unit that are not "interface" (e.g.,= =20
non-template function definitions) probably need to be pre-compiled and= =20
linked into the distributed library (which may have its own dependencie= s=20
on them) unless the expectation is that the recipient link objects=20
produced by compilation of module interface units into their respective= =20
binaries (which seems to me a good recipe for ending up with duplicate= =20
definition errors at link time).=C2=A0 I'm very curious to see how = build=20
systems are going to end up managing this.

So you have the choice whether you shi= p the source files or a binary version of it. OK.=C2=A0

Deduced how= ?

Take this code for example:

//sample.cpp

namespace samp= le
{

struct event
{
=C2=A0=C2=A0= =C2=A0 std::string message;
=C2=A0=C2=A0=C2=A0 std::string details;
= =C2=A0=C2=A0=C2=A0 std::string file;
=C2=A0=C2=A0=C2=A0 uint line;
};=

class event_printer
{
=C2=A0=C2=A0=C2=A0 us= ing format_fn =3D std::function<void(std::string& str, const event&a= mp; ev)>;
=C2=A0=C2=A0=C2=A0 std::vector<format_fn> m_functions= ;
public:
=C2=A0=C2=A0=C2=A0 event_printer(const std::string& for= mat);
=C2=A0=C2=A0=C2=A0 std::string format(const event& ev) const=C2=A0=C2=A0=C2=A0 {
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 std::string= res;
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 for(const auto& fn : m_f= unctions)
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 fn(re= s, ev);
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 return res;
=C2=A0=C2= =A0=C2=A0 }
};

}

From = this code, you can easily say that importing this file will import the decl= aration of the 2 structs, the first one being just a POD data type, while t= he second will have a ctor from a std::string and also a method format with= the given signature.
Note that in this example, the implementati= on of the ctor and the format method could be in the same cpp file but don&= #39;t require to, since the declaration of the class is enough.

The problem we have today with headers is that everything
in a header needs to be parsed, whether part of the actual
interface of the library or not.

= The idea here is to parse the file only once and to save the "visible&= quot; part of it in a specific file. The next time this file will be import= ed, we could just extract the visible part from the generated file (since t= he source file didn't change since the other one was generated), avoidi= ng then to re-parse the source.

Modules give us control over what
things are part of the interface and what things are not.

Yeah, something in my approach is mo= re or less missing here. More or less I said? Yes, because in fact this par= tially already exists. I mean, take this code for example:

//sample_details.cpp

static void print_me= ssage(std::string& msg, const event& ev)
{
=C2=A0=C2=A0=C2=A0 msg.append(ev.message);
}

Here you know that the method print_message won't be ex= ported by the compiler, and thus non-visible outside of the sample_details.= cpp file. Even if you import this file (which shouldn't be done if we t= ake the logic of my example into account), this method won't be importe= d because it is internal to the sample_details.cpp file.
In fact,= this mechanism is inherited from C, meaning that it exists from a long tim= e. But unfortunately, it use the static keyword, which could have different= meanings when used inside a class. Perhaps deprecating the use of static i= n this context and replacing it by something else (say internal for example= ) could do the trick.

So i just give you a sma= ll example of how I saw things, but there are probably a lot of related pro= blems which need to be resolved, for example how template should be handled= when using this model. I didn't try to solve all this since my goal is= just to make you understand what I mean by "an approach where the exp= orted symbols are deduced from the code". Also I believe that most of = the choice made for the module proposal could apply to this model as well.<= br>

Masse Nicolas.

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/9f2c63e2-7904-49ea-a2ac-87e80fe78e78= %40isocpp.org.
------=_Part_82_2139354162.1544565990604-- ------=_Part_81_1128770004.1544565990604-- .