220 3651 <622154c0-c112-4756-bfd0-123188e9c398@isocpp.org> article Path: news.gmane.org!not-for-mail From: sgheeren@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: N3573: Why heterogenous extensions to unordered containers will not work Date: Tue, 9 Apr 2013 04:38:38 -0700 (PDT) Lines: 76 Approved: news@gmane.org Message-ID: <622154c0-c112-4756-bfd0-123188e9c398@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5370_27775616.1365507518614" X-Trace: ger.gmane.org 1365507517 13992 80.91.229.3 (9 Apr 2013 11:38:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 9 Apr 2013 11:38:37 +0000 (UTC) Cc: jgottman6@gmail.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCL4V2426AARBP73R6FQKGQEZ7MKZJQ@isocpp.org Tue Apr 09 13:38:41 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-gh0-f197.google.com ([209.85.160.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UPWsr-0001SD-6b for gclcip-std-proposals@m.gmane.org; Tue, 09 Apr 2013 13:38:41 +0200 Original-Received: by mail-gh0-f197.google.com with SMTP id r17sf9475763ghr.0 for ; Tue, 09 Apr 2013 04:38:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:x-beenthere:x-received:date:from:to:cc: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=lKgvDECo66OOsoJntWDTh3Xs7UgKCzP6Lh3DV5nDgFc=; b=VaJkdZ3a5QqBIZQof5BcUKqJ799HkXL1wIeUCS3cVos1O6grrODOgmd+bGrIZEsbLA 1xrStp69hCQOdvta6OUy5MjcJjcqOJxEVxyP3gRsqJm4axJeteE7dFsRa1LdjZmbvSXx 1WSneUJPvJLVxVCs4dABveiKDOjoQpvLprT0GMPndMzjjwI0nAglbPekNcAx54lh7cmr IYHAF6fkLL6lOPdnTLOl8IevVja/3sWkFCjnQLv5s/cYKqP36Zo//7ZM7OaIDcgDpM2C FRVRSB9LqIA78hebkyJkQ0krysQM91Pznck1cpGgCwAIktMsaepFG922XjkxK+8S9hYE PgBA== X-Received: by 10.236.118.161 with SMTP id l21mr11799766yhh.44.1365507519913; Tue, 09 Apr 2013 04:38:39 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.130.227 with SMTP id oh3ls2818109qeb.57.gmail; Tue, 09 Apr 2013 04:38:38 -0700 (PDT) X-Received: by 10.49.71.50 with SMTP id r18mr2040262qeu.26.1365507518862; Tue, 09 Apr 2013 04:38:38 -0700 (PDT) In-Reply-To: X-Original-Sender: sgheeren@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:3651 Archived-At: ------=_Part_5370_27775616.1365507518614 Content-Type: text/plain; charset=ISO-8859-1 On Tuesday, April 9, 2013 12:58:15 PM UTC+2, DeadMG wrote: > > ... and secondly, I did not consider a moving erase. Currently, it is > impossible to move an element out of a map/set/unordered_map/unordered_set, > which is a bit painful IYAM- my previous use cases simply did not require > it, so I didn't consider it. Obviously this would have to be > move-out-and-erase in one step to prevent violating the invariants of the > container. Have you had look at proposal n3586 "Splicing Maps and Sets"? Seems to address the same usecase area: As technically a splice method is not possible for maps or sets, the goal > is to add a new function called remove, which returns a unique pointer > holding the node, and add a new overload to insert, allowing to insert the > node into the new container Seth -- --- 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/?hl=en. ------=_Part_5370_27775616.1365507518614 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tuesday, April 9, 2013 12:58:15 PM UTC+2, DeadMG wrote:
... and secondly, I did not consider a moving e= rase. Currently, it is impossible to move an element out of a map/set/unord= ered_map/unordered_set, which is a bit painful IYAM- my previous use cases = simply did not require it, so I didn't consider it. Obviously this would ha= ve to be move-out-and-erase in one step to prevent violating the invariants= of the container.

Have you had look at pro= posal n3586 "Splicing Maps and Sets"? Seems to address the same usecase are= a:

As tech= nically a splice method is not possible for maps or sets, the goal is to ad= d a new function called remove, which returns a unique pointer holding the = node, and add a new overload to insert, allowing to insert the node into th= e new container 
 

Seth 

--
 
---
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-pro= posals/?hl=3Den.
 
 
------=_Part_5370_27775616.1365507518614-- .