220 6801 article Path: news.gmane.org!not-for-mail From: Robert Zeh Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Modules before adding Concepts Date: Mon, 30 Sep 2013 10:57:45 -0500 Lines: 92 Approved: news@gmane.org Message-ID: References: <38703f65-fe3b-4eea-8fe9-6729edd5e76a@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e014942eea9b74e04e79be58f X-Trace: ger.gmane.org 1380556668 9938 80.91.229.3 (30 Sep 2013 15:57:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 30 Sep 2013 15:57:48 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCQKVE6D7QCRB6V6U2JAKGQELU4ELYY@isocpp.org Mon Sep 30 17:57:52 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ea0-f200.google.com ([209.85.215.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VQfr2-0007cu-0m for gclcip-std-proposals@m.gmane.org; Mon, 30 Sep 2013 17:57:48 +0200 Original-Received: by mail-ea0-f200.google.com with SMTP id q16sf6872157ead.7 for ; Mon, 30 Sep 2013 08:57:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=y5kLlHmEvRbwdTLAvtpVqfLfWu/91g8hMnZeVcBUgfQ=; b=jmNZGmixSYajNKr2xR6KV95MUT46ju6Mdfu8mDHYvvEjrdoVHvt3HxoB8cigBgiAAD 79pKp0xXfrnxq11i+atpothlpL8afj3GUdVtoTj9aU6Za6jW1tOn7VdcIHK9tw81Jo7K 5vXbIseskZ4MStQW1QaHvfE85cOyCnR6EjTXo9cihRAJJ8W5zWMA1frdsDZ1hcHrCi9Q V8bEzP/ZTdaFMeXq9zURBM+DX7OkSa/i8QhYdG3ouxlRhDo2I7NoRjboizNBWjLQSd67 s/sNjElJsf6FSmmUsQX+/ZEcrZt8c745l+aJ0d9ynEATT4dxAbHjRptXM3+CkN5EbpqV u2/w== X-Received: by 10.180.208.103 with SMTP id md7mr8333618wic.0.1380556667051; Mon, 30 Sep 2013 08:57:47 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.91.226 with SMTP id ch2ls601030wib.30.canary; Mon, 30 Sep 2013 08:57:46 -0700 (PDT) X-Received: by 10.204.232.207 with SMTP id jv15mr2405725bkb.39.1380556666339; Mon, 30 Sep 2013 08:57:46 -0700 (PDT) Original-Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [2a00:1450:4010:c04::22c]) by mx.google.com with ESMTPS id ub7si209896bkb.115.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Sep 2013 08:57:46 -0700 (PDT) Received-SPF: pass (google.com: domain of robert.a.zeh@gmail.com designates 2a00:1450:4010:c04::22c as permitted sender) client-ip=2a00:1450:4010:c04::22c; Original-Received: by mail-lb0-f172.google.com with SMTP id x18so4701353lbi.17 for ; Mon, 30 Sep 2013 08:57:45 -0700 (PDT) X-Received: by 10.152.18.131 with SMTP id w3mr2061791lad.47.1380556665893; Mon, 30 Sep 2013 08:57:45 -0700 (PDT) Original-Received: by 10.114.48.6 with HTTP; Mon, 30 Sep 2013 08:57:45 -0700 (PDT) In-Reply-To: <38703f65-fe3b-4eea-8fe9-6729edd5e76a@isocpp.org> X-Original-Sender: robert.a.zeh@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of robert.a.zeh@gmail.com designates 2a00:1450:4010:c04::22c as permitted sender) smtp.mail=robert.a.zeh@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: 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:6801 Archived-At: --089e014942eea9b74e04e79be58f Content-Type: text/plain; charset=ISO-8859-1 On Mon, Sep 30, 2013 at 10:07 AM, snk_kid wrote: > I started to think that maybe the community is going about this the wrong > way, maybe the first step and the highest priority above everything else > should be to standardize a module system so we can get away from textual > inclusion we have now. Then come back to features, features which can have > an influence (and influenced by) compilation times and see how they perform. > > To me it does not seem to make much sense to to accept/reject solutions > which are disadvantaged by an old/outdated system (textual includes) that > everyone knows the issues with it and we eventually be replaced. > > > I agree that the compile times for projects over 1 million lines of code makes life difficult --- it has certainly made my life difficult. Fixing it is important, and it will most likely be fixed by modules. However, I haven't been able to find a single priority queue for the community :-) The people working on modules are not fungible with the people working on concepts for a lot of reasons, but keep in mind that they they are also volunteers. Volunteers work on what they want to work on. It is not as if all the other standardization work (sized dealloc, filesystem, concurrency, etc) is being done at the expense of modules. One thing you could do is to talk to the people working on modules and see if there is anything that you could help with. Robert -- --- 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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. --089e014942eea9b74e04e79be58f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon, Sep 30, 2013 at 10:07 AM, snk_kid <korcan.hussein@= googlemail.com> wrote:
I started to think that may= be the community is going about this the wrong way, maybe the first step an= d the highest priority above everything else should be to standardize a mod= ule system so we can get away from textual inclusion we have now. Then come= back to features, features which can have an influence (and influenced by)= compilation times and see how they perform.

To me it does not seem to make much sense to to accept/reject solutions= which are disadvantaged by an old/outdated system (textual includes) that = everyone knows the issues with it and we eventually be replaced.



I agree that the compile times for proje= cts over 1 million lines of code makes life difficult --- it has certainly = made my life difficult. =A0Fixing it is important, and it will most likely = be fixed by modules.

However, I haven't been able to find a = single priority queue for the community :-) =A0The people working on module= s are not fungible with the people working on concepts for a lot of reasons= , but keep in mind that they they are also volunteers. =A0Volunteers work o= n what they want to work on. =A0It is not as if all the other standardizati= on work (sized dealloc, filesystem, concurrency, etc) is being done at the = expense of modules.

One thing you could do is to talk to the pe= ople working on modules and see if there is anything that you could help wi= th.

Robert

--
 
---
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-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
--089e014942eea9b74e04e79be58f-- .