220 41182 article Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Modules and preambule, just why? Date: Sat, 1 Dec 2018 14:39:35 +0100 Lines: 237 Approved: news@gmane.org Message-ID: References: <16989401-2f0d-4200-997e-0ac60b47bec3@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1543671487 13292 195.159.176.226 (1 Dec 2018 13:38:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 1 Dec 2018 13:38:07 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD3NR2WQQ4IBBPE6RLQAKGQECLRRFHY@isocpp.org Sat Dec 01 14:38:03 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vs1-f70.google.com ([209.85.217.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gT5T8-0003Jq-PM for gclcip-std-proposals@m.gmane.org; Sat, 01 Dec 2018 14:38:03 +0100 Original-Received: by mail-vs1-f70.google.com with SMTP id m5sf4126767vso.5 for ; Sat, 01 Dec 2018 05:40:13 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1543671613; cv=pass; d=google.com; s=arc-20160816; b=N9t0U0bJPhc8F2l9NhuNNDgaYWMOEB71ALDSLBoyEN539ifxRT+LWVvqntDKvQw85/ 1P1V/JGl+kqXK8Ec0ecolXYJYyFkf0IiOHUZ6LLRpMl7zS7qg5ieKyn5lmHzHQiEO6ib tIBhXBl45bxZlWybYO8QCNyBe3iSbEIlqK7VBqXrH3L8DeuXsAWbo6tsP4NeKw2ynQY7 4mQP0gLWPFLnhvouO12GgfFx8lM7Q+qlUiChKXjxVHh1+gQmQP41dSMoaifm5+wlMEKN 8hHccqMXjw7fb4N4OK9myO1JFPeL09e7r9Az7rFTSAdFyWUMAEdU2p/1eK//d5ETXTZG L4Yg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:content-transfer-encoding :to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=ZduDlBWXvbHW2J3BRHIhYsNTdoLaTR1WIF7enzuLBBY=; b=f75+H+1AN7eJeC1rHqMZJCh1cl7OTz4mR90bA2DRJnNVLcncPt9WdEDzmo3AFa5t0u PrcuJcXRC7rgduOTDMesgX5+EkTaEz2kcBlUsI22Em6W+5dBQIDQkBS81sf9vkcwHrsx TFaP5XN7M+M5jQ8qYx/3pvVUWTF1Of5OnERpLHXF3A7rJXCexHsfi0DAyPwJacJoKv+g kYCgo1TDBAhw8UBTmersJ3h8yxruJ+x/xojrCOr/y5qm73pBYoCu8sUnr1MjssP9291H em8I9rQwOIgDer35/+ben+RNnpuUnx3FT3jm2B85/H7Gaw3wo7LWACI8p31+/+m2uCuV lP+Q== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=uKhnaUzg; spf=pass (google.com: domain of mjklaim@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=mjklaim@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=ZduDlBWXvbHW2J3BRHIhYsNTdoLaTR1WIF7enzuLBBY=; b=F3bi2vgyL4XvaaI78gaHw+7HEhkfra+QVovQEyHM7dD1xI6CmOAlRP91HfpUfo622p za+uFZitTXoqtLsXUXJMBfc8BWlIyOzeV2bh7SIN9GFw0oaIv0v9JIJdmzl63BoEIAAd fWyk64RiPGpuAQ58d3EdqGZDWU0GIH9WW80IbDkE+grrM9MkQbIjDsMrPx2vYJlPFbjB PleIzT2QeAICwWNGtM9AsZdkKESb0fqiCBeCu+5sW7rhGEteZIdiutpr+/bAb23YY6CL dbvP6iiSeRrU1090/QMFPVtD6yoUMqnc2xiK3TPQM3vUytzbGgcnRqPrjdc5LGYEi9ru acZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=ZduDlBWXvbHW2J3BRHIhYsNTdoLaTR1WIF7enzuLBBY=; b=h1zsGNnwCB57vknZHD9avMTQDWrdhqQWU10UptzoQycKRH7XeQZSSabUWIc/hwuuEg UnY3WAHp13XXmKjUj7fOxgl/yzdUwScSvtKdAYnvT7mEFNC2nB4GEWtfyRlmM/Aa3nhb dzKjnjpqwOjKWHN0c9FXPvt2Wj5Bf9MXjkMuEuq9f1LnjzGMh9xT/YfbK4Q7yVGJ5JJv UQ/kAaVHQPxzrRrz4vWDwYyj7FCW9/Hsi0w5zewxt1Lyf03iKj2+FO6LXJvxbjtZAs1e uvckb+4XDPkeq4CEZQk6QDhkQOwdKPYMGPfhcH0V+1DJmzqCq6d2vv+cMw/DXgzmlBoz pHf X-Gm-Message-State: AA+aEWaWk3l2CJlCqE+1QeWUYBpSBXWi/u5qgNqU/CVsDffXwJNZATTH Uz02OW8YnNlvxkTGsUcdJf6YQA== X-Google-Smtp-Source: AFSGD/U+ZuCxYYj5iU5XL7E0GGHAAcNBhPlJWVBx3a+ABYjpUM7XbohcH9nFgwZNmrUVuyHgr/WcAQ== X-Received: by 2002:a67:44c2:: with SMTP id y63mr8288945vsf.34.1543671612845; Sat, 01 Dec 2018 05:40:12 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:ab0:6248:: with SMTP id p8ls1701260uao.0.gmail; Sat, 01 Dec 2018 05:40:12 -0800 (PST) X-Received: by 2002:ab0:7618:: with SMTP id o24mr4335223uap.110.1543671612049; Sat, 01 Dec 2018 05:40:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543671612; cv=none; d=google.com; s=arc-20160816; b=HeZ/OQk/XIbxrlB6jZ94bZdPc9o2xNLZPgyCtJHuMmGV+HHK31/yV5PV/CzWlpOvt0 V++pZ8e0BB0UmnQPD2gOkyMvN3vH5smWRX0asIxb07qhD7ri68dpLc1XAZwqgXja7S7y cMiN2Hk4QSmuPoJ0ZuXJXXJFuGO4d03nFqg0YRj3uvhC+Aeql5Cc8NGoc+W++2w27Ve6 734320XNW8JslwmkfPqt4f8zKOxX9/B+STfWTbMfi5IMdZTXbSIpbI/dwS1kJZB//BfJ bNVZQALJwniBItp+S/3GLpJqZZl1NE6zxCubpqjc6tZMLBG2DjoWennb39dWMOz83TgD EpKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=VI5LH5AE9RxC4XT+vUkwdyvjdbjC0AGbN9aenA1g8Qs=; b=Rn+pTjHfTPo6t5VOERcm69oyJmFjr9YIlNfyUcB+8lnJ/Jwla0RuLwNN0rPBTahtWk NORWgvRL/n50V0onRPylU+PBdBrCv1WTkwdSAQchI41lL+Tr+wcL6Mvd2AudOI9BaeKZ jT8irC7lW+kKbK534Hm6+gvo0/3mNMMdgkHo9bGPHMjJTS+dLDw06tP00CLTjvv+ggIp vC1+1JO/sS+F7ebGklU8fUB2UZU4O61W9u2tX0MFlKsoNKxa8Ne2Xb7zu25Tys3LntFA oM6W3/C1IVWhEeG3LGjho8d6UdO9U6UnuASlzTvQC41ZBAMIKQISDGo1vdGS/PNPP01I wBJg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=uKhnaUzg; spf=pass (google.com: domain of mjklaim@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=mjklaim@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id r72sor4287514vsf.91.2018.12.01.05.40.12 for (Google Transport Security); Sat, 01 Dec 2018 05:40:12 -0800 (PST) Received-SPF: pass (google.com: domain of mjklaim@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 2002:a67:3d54:: with SMTP id k81mr4140757vsa.57.1543671611251; Sat, 01 Dec 2018 05:40:11 -0800 (PST) In-Reply-To: <16989401-2f0d-4200-997e-0ac60b47bec3@isocpp.org> X-Original-Sender: mjklaim@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=uKhnaUzg; spf=pass (google.com: domain of mjklaim@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=mjklaim@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=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:41182 Archived-At: On Thu, 29 Nov 2018 at 23:40, masse.nicolas@gmail.com wrote: > > Hi, > > Le mercredi 28 novembre 2018 12:16:53 UTC+1, Klaim - Jo=C3=ABl Lamotte a = =C3=A9crit : >> >> On Tue, 27 Nov 2018 at 22:10, wrote: >> > The way modules have been done, they require the sources files to decl= are which module they implements and what they exports into a preambule. >> > To be honest, I don't really get why this was necessary. >> >> My understanding is that the main reason is that it helps tools know >> the dependencies without having to parse the rest of the C++ syntax. >> Build systems will have to check every source file in a first pass to >> quickly decide what have to be built, by making a dependency graph. >> This pass is simple if the information is easily locatable and with >> always a strict subset of possible C++ syntax. > > > 2 things here: > - The dependency graph could be quite hard to compute and will require to= parse every source files. While this is viable on small projects, this cou= ld (and probably will) be a problem on large ones. So far build2's main author reports no problem with this, as long as the preamble is easilly parsable without having to have a complete C++ parser. Also it seems to help making the rest of the compilation process faster. I have some hello world using modules if you want to try them as a starting point for converting a library and see if you see improvements? > - So far, dependency have always been computed from the build system itse= lf, by specify which files are part of a library, and what other libraries = are needed to create each one of them. That part do not change as module have nothing to do with the dependency graph at the link level. > Basically this is the opposite approach where this information is describ= ed in the build system and is not know by the sources files. And so far, I = do believe this model works well and doesn't require to be changed. I think you're mixing the end result programs (exes, dlls/so, static libraries) with modules. A C++ language module have nothing to do with the actual generated binaries. It's code compartmentalization mainly. You can have 10 modules in one so or in one exe, or in a module-interface-only library (like a header-only library). > Also, the way you phrase it seem to indicate we're modifying the language= to help other tools (not compilers) to deal with it. I hope it's not the c= ase. Modules add to the language, it doesn't "modify" the current one. Tools are handicapped by the current include system. Why would it be not the case? How do you want something like an IDE extension trying to deduce where the words in the line you're pointing to are from? They need to know the dependencies of the context. Also the main tool that this helps is build systems, that can then easily expose the dependency graph (of modules, not of binaries, which they already do). >> >> > Moreover, i found some drawbacks with it: >> > - It makes sources files dependent on which modules they will be shipp= ed in. >> >> I'm not sure I understand this point. >> Isn't it the point of modules to associate a module name to sources? > > > I don't think so. > I think the point here is how to export the functions, global variables, = .... in a more efficient way than using header files (eg: by avoiding to par= se and reparse the same code every times an header is included). Here in the context of modules, "export" means "making these names visible to the importer", it does not mean something like dllexport. Just clarifying because the way you point this is weird to me, in this cont= ext. Other than that I agree with you and it seems to do exactly that: modules are compiled once. The preamble pre-reading to build the modules dependency graph is trivial compared to what is needed to parse the language for compilation. > Note that after reading http://www.open-std.org/jtc1/sc22/wg21/docs/paper= s/2014/n4047.pdf, it seems they also speaks about "componentization", but i= 'm usure the current proposal is the best way to achieve it (exporting or n= ot a symbols can for example already be specified using the visibility attr= ibute when using clang/gcc). > Modules do nothing to symbols. They componentize names. If you want to export symbols, as in making a function in a .so/,dll usable by another program, you stil have to add some dllexport/import macros as it have nothing to do with modules. I have an example here where I use some import/export macro (symexport) in addition to a module export: https://github.com/Klaim/build2-libhelloworld-exe-modularized/blob/master/l= ibhelloworld-modules/helloworld-modules.mxx (The syntax is the one implemented in VS 15.9 so it's Modules TS syntax, not more recent Module proposal version). Note that there is another proposal for a library API for helping with plugins. But again this have nothing to do with modules. >> >> > - Not only the sources does declare the module they belongs to, but th= ey also need to be put together in the build system (may it be Makefiles, c= make, ...). This goes against the DRY concept since it cause duplication of= information. >> >> I don't understand where would be a duplicate information. The module >> names exist only in sources, not in build system's project description >> files (at least in any decent build system). >> > As said above, this is basically the opposite approach. Again I think you're mixing binaries dependencies and modules (as in code-only) dependencies. > By the way why do we need to put your files together in the source code i= nside a module while we already put them inside the same library or executa= ble at the build system level? The basic idea is that it depends on how you like to organize your code. Modules are designed to not get in your way with this. So if you want to have all the code in one module file (which then is the module interface, with a public eported part, and maybe another part not exported), nothing prevent you to do so. If you want to splitt 1 Module into say 10 source files, you have different ways to do so. The main thing is that at the end there is only one file that defines what the module exports. If you want to splitt your module in several modules then make one of the module export the others, you can also to that. If you want to have only the module interface containing exported names, and all the other source module files having the definitions, you can. Etc. Organize as you want, the only constraint is that for one module, there needs to be one file that will export the names for importers. The details of how to do these is longer to explain but I think several talks and papers can help with that. Again, this have nothing to do with the binary linking part of the process of building programs, so you can have 10 modules in a .so or in a exe if you want. >> > - There is a concept of 'module interface unit' (and even a 'primary m= odule interface unit'!). As far as I understand it, it is almost the same t= hat old .h files, thus providing no real benefit over the latter when writi= ng new code. >> >> Of course it provides benefit! It's like saying that a header file and >> a module is similar, but it's really not. For example, your header >> will leak it's names into user's user's code. Modules will not by >> default. >> >> The point of these interface unit is to allow you to not change the >> interface but change the implementation without the user aving to >> recompile their code, even if all the module code is defined in one >> file. > > The interface/implementation separation is already there when using heade= r files, so what you describe here seems to me already possible. > I'm not sure to get your point here. > Ok, to clarify: it's kind of the same idea but done in a different way which removes the issues with headers. Among numerous issues, headers (assuming with only interfaces exposed in them), cannot guarantee independence of what they expose. #include "aaa.hpp" // void foo(Bar b); #include "bbb.hpp" // #define Bar Kikoo Can give a different code than #include "bbb.hpp" // #define Bar Kikoo #include "aaa.hpp" // void foo(Bar b); Here both headers interract because in the end their content only exist in the cpp including, so they impact each other. You can try to make sure that your headers will always produce equivalent code whatever the the other includes around (we call these "well behaved" and there is a proposed mechanism to help use them as if they were modules), but you are still dependent on them and external ones because just one header could redefine any word used in the following header included (mainly through macros). With modules: import aaa; import bbb; and import bbb; import aaa; Are stictly equivalent, by design, whatever is define in these modules. Importing one will not change the other as macros are simply not imported, and only names/signatures can be exported. Because this is only importing names from these modules in the set of possible names that could be found when you try to use a name. But you are right that in essence the module interface solve the same problem (better) than having headers with only interfaces declarations/definitions. >> As you can see, it's a fix of the preamble, not a removal. > Yes, unfortunately. I'm not sure what is the problem with the preamble exactly? Did you want to import from another place? > > > Thanks for your answer, No problem. :) Jo=C3=ABl --=20 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 e= mail 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/CAOU91ONR5v9ujCaM5Riu5Dc39cejV4VcMEdieF3O6b_edy%= 2BY7g%40mail.gmail.com. .