220 5519 article Path: news.gmane.org!not-for-mail From: Steve Heller Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: A library to provide a virtual memory vector of strings Date: Tue, 23 Jul 2013 12:19:39 -0700 (PDT) Lines: 102 Approved: news@gmane.org Message-ID: References: <861959e9-74f3-4ed8-aeca-bad9c3256acd@isocpp.org> <52729d06-72f4-4d9d-a000-7cfa3af9837a@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5_30100161.1374607179866" X-Trace: ger.gmane.org 1374607180 30290 80.91.229.3 (23 Jul 2013 19:19:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 23 Jul 2013 19:19:40 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDG2H26ZRUARBTFOXOHQKGQEC4JXWFI@isocpp.org Tue Jul 23 21:19:42 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qa0-f70.google.com ([209.85.216.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1V1i7Z-0006kQ-VG for gclcip-std-proposals@m.gmane.org; Tue, 23 Jul 2013 21:19:42 +0200 Original-Received: by mail-qa0-f70.google.com with SMTP id cd7sf4613007qab.9 for ; Tue, 23 Jul 2013 12:19:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-beenthere:date:from:to:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:x-google-group-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=k5KRwtOgTBXCWv4wD42gFLe23y9JBoTzyJ2WYVWQ9iM=; b=QvRawLon+er6O3GRV0hJ3Q/9BtEPzhmoaQBD8MwaXlNRcMr9AcvMGiixfm5n7gjY2C PvZYVSAcwFU5Yup3xqtsbA7bRMpY65yx0BWxJHC72z0LXnyveRl7yc7QW13NbsctvIYg nldiEtfkXgqakea0v+U3mRnc3coDNKPgD/dAU313TFzWPqGQRDD/BUG24EN8Zyt3JE7u umJAG76H++sUEFau2VM9dE5e+FUdjShQmw3Fp7FZ1kJyO2xEdW6gq7OQ2v9PGQDAiecn FJx4WBfixZKalrt5o9n0SJ1ty+JV50J2MJMTYNmdOkx7T46QmZ5fqpYLeMajVvxDFlLh BzjA== X-Received: by 10.236.83.82 with SMTP id p58mr17932735yhe.10.1374607180993; Tue, 23 Jul 2013 12:19:40 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.16.195 with SMTP id i3ls3090874qed.17.gmail; Tue, 23 Jul 2013 12:19:40 -0700 (PDT) X-Received: by 10.49.36.199 with SMTP id s7mr1301892qej.17.1374607180281; Tue, 23 Jul 2013 12:19:40 -0700 (PDT) In-Reply-To: X-Original-Sender: technovelist@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:5519 Archived-At: ------=_Part_5_30100161.1374607179866 Content-Type: text/plain; charset=ISO-8859-1 On Tuesday, July 23, 2013 1:59:36 PM UTC-5, Nicol Bolas wrote: > On Tuesday, July 23, 2013 7:45:28 AM UTC-7, Steve Heller wrote: >> >> I admit that it *sounds* very special-case. But in practice it is a lot >> more flexible than that. For example, my employer's programs use it in two >> quite different applications, neither of which is a general string type. >> Instead, it is used as the underlying storage mechanism for caching SQL >> database records and for a domain-specific record type that is converted to >> and from string representation (in this case, by the MFC CArchive facility). >> >> So rather than thinking of this as a virtual memory character string >> facility, think of it as a mechanism for implementing file-based >> variable-length data objects, and its more general applicability becomes >> evident. >> > > If that's what it's for, then you should probably describe and propose it > that way. > > Another thing I'm leery about is that you seem to be describing the > implementation, rather than the behavior. The standard is generally built > around describing behavior, thus allowing implementers the freedom to > implement it as they see fit. > > Tying this memory to files, for example, seems to be an implementation > detail. Is there a more general way of describing it without dealing with > implementation details? > Ok, I'll see if I can recast the description as an infrastructure for variable-length virtual memory data. As for the tie to a file being an implementation detail, I can't think of any reason it couldn't use a raw disk rather than a file system, but I've never implemented it that way. -- --- 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_5_30100161.1374607179866 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tuesday, July 23, 2013 1:59:36 PM UTC-5, Nicol Bolas wrote:
On Tuesday, July 23, 2013 7:= 45:28 AM UTC-7, Steve Heller wrote:
I admit that it sounds very special-case. But in practice it is a l= ot more flexible than that. For example, my employer's programs use it in t= wo quite different applications, neither of which is a general string type.= Instead, it is used as the underlying storage mechanism for caching SQL da= tabase records and for a domain-specific record type that is converted to a= nd from string representation (in this case, by the MFC CArchive facility).=

So rather than thinking of this as a virtual memory characte= r string facility, think of it as a mechanism for implementing file-based v= ariable-length data objects, and its more general applicability becomes evi= dent.

If that's what it's for, then you should p= robably describe and propose it that way.

Another thing I'm leery ab= out is that you seem to be describing the implementation, rather than the b= ehavior. The standard is generally built around describing behavior, thus a= llowing implementers the freedom to implement it as they see fit.

Ty= ing this memory to files, for example, seems to be an implementation detail= .. Is there a more general way of describing it without dealing with impleme= ntation details?

Ok, I'll see if = I can recast the description as an infrastructure for variable-length virtu= al memory data.
As for the tie to a file being an implementation = detail, I can't think of any reason it couldn't use a raw disk rather than = a file system, but I've never implemented it that way.

 =

--
 
---
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_5_30100161.1374607179866-- .