220 6993 article Path: news.gmane.org!not-for-mail From: fmatthew5876@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: About N3716 - A printf-like Interface for the Streams Library Date: Fri, 4 Oct 2013 21:11:55 -0700 (PDT) Lines: 103 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1370_32721653.1380946315940" X-Trace: ger.gmane.org 1380946315 21643 80.91.229.3 (5 Oct 2013 04:11:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 5 Oct 2013 04:11:55 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDELF54RTIGRBDFDX2JAKGQECJVP3WY@isocpp.org Sat Oct 05 06:11:59 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qa0-f69.google.com ([209.85.216.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VSJDi-00015F-05 for gclcip-std-proposals@m.gmane.org; Sat, 05 Oct 2013 06:11:58 +0200 Original-Received: by mail-qa0-f69.google.com with SMTP id cm18sf4345091qab.4 for ; Fri, 04 Oct 2013 21:11:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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 :content-type; bh=cfr8TJhRWFmHBG5rubkQBR+PYMM8o0tTwhxo3fBDcGc=; b=vughAwOYtlFWDfgPdn0tBUU+ayWW91Upz4un3/Vexxdll0j6kP+YSalHouX1X0082s mzzocjdr+TptCAvdHNqn/wobOr6+maKCNlvhL/rVFXCOSfcoHPx1Ikd0tDoIECiqrrF2 WhoqZENcKkgL6vlvzLf4vXLGKGkH22Wp9ISWXcI54D39RFsfFcj7Nme/OECAQe6o4kGy x3i/ND4860rFBlM9oA2iPl/Vz0C+fVyy01l59hM1hmuAL9SOevIam6V+soXiyHy5TYUM HlpcSpIXfMI1X8ijV1vcQ8X7kX/V4C9g5wjZKf/J2yR9C6aLZkFea1t4WeJ4lz2oOevs qKFA== X-Received: by 10.224.137.67 with SMTP id v3mr29374597qat.0.1380946316968; Fri, 04 Oct 2013 21:11:56 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.0.12 with SMTP id 12ls1573874qea.25.gmail; Fri, 04 Oct 2013 21:11:56 -0700 (PDT) X-Received: by 10.49.71.34 with SMTP id r2mr230qeu.14.1380946316562; Fri, 04 Oct 2013 21:11:56 -0700 (PDT) In-Reply-To: X-Original-Sender: fmatthew5876@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:6993 Archived-At: ------=_Part_1370_32721653.1380946315940 Content-Type: text/plain; charset=ISO-8859-1 Honestly I don't know that I like this idea just yet. What I would dream about is one formatting solution to rule them all. Right now we have printf and oprerator<<() and complex reasons to choose one or the other. Now with putf(), we have 3. If putf is efficient and can do everything, its a no brainer for sure. If its more readable, type safe, easy to use, allows extra semantics like locking, then operator<<() can be retired. If its not as fast as printf however, there is still a valid reason to use printf. Especially for people who run into situations where the logging subsystem is the botttleneck. I've it happen because of allocating strings to contruct messages and dealing with iostreams. Second, we MUST have the ability to format into a memory buffer, I do this all of the time with snprintf. If putf has to use a stringstream or other iostream operations to print user defined types, it may be impossible to match or beat printf. My nightmare is the only thing gained from this is now we have 3 options which are all insufficient in different ways. I believe strongly that variadic templates are the correct solution for a printf/operator<<() marraige. I don't think it should be mixed with operator<<(). operator<<() should be legacy because operator overloading is unnessary an clumsy for this task compared to variadic templates. cout << putf(/*stuff*/); //bad, we leave a dependency on iostreams. There is rumblings of a replacement. Also the << is unnessesary cruft putf(cout, /*stuff*/); //better, works well with iostream but not dependent on operator<<(), easily could support more destination objects like std::string, std::vector, char*/size_t, etc.. -- --- 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/. ------=_Part_1370_32721653.1380946315940 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Honestly I don't know that I like this idea just yet.
W= hat I would dream about is one formatting solution to rule them all.
Ri= ght now we have printf and oprerator<<() and complex reasons to choos= e one or the other.

Now with putf(), we have 3. If= putf is efficient and can do everything, its a no brainer for sure.
<= div>
If its more readable, type safe, easy to use, allows extra semantic= s like locking, then operator<<() can be retired.
If its no= t as fast as printf however, there is still a valid reason to use printf. E= specially for people who run
into situations where the logging su= bsystem is the botttleneck. I've it happen because of allocating strings to= contruct
messages and deal= ing with iostreams. Second, we MUST have the ability to format into a memor= y buffer,
I do this all o= f the time with snprintf.

If putf has to use a stringstream or other iostream = operations to print user defined types, it may be impossible
to m= atch or beat printf.

=
My nightmare is the only thing = gained from this is now we have 3 options which are all insufficient in dif= ferent ways.

<= /div>
I believe strongly that variadic= templates are the correct solution for a printf/operator<<() marraig= e. I don't think
it shoul= d be mixed with operator<<(). operator<<() should be legacy bec= ause operator overloading is unnessary an clumsy
for this task compared to variadic templates.

cout << putf(/*stuff*/); //bad, we leave a d= ependency on iostreams. There is rumblings of a replacement. Also the <&= lt; is unnessesary cruft
= putf(cout, /*stuff*/); //better, works well with iostream but not dependent= on operator<<(), easily could support more
destination objects like std::string, std::vector&= lt;char>, char*/size_t, etc..

--
 
---
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>.
------=_Part_1370_32721653.1380946315940-- .