220 8905 article Path: news.gmane.org!not-for-mail From: Ville Voutilainen Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Comments on 2d api for c++ N3888.pdf Date: Tue, 28 Jan 2014 23:28:55 +0200 Lines: 44 Approved: news@gmane.org Message-ID: References: <9105f9b2-e15d-4bf8-a4a1-65ebc3657eb0@isocpp.org> <4305077.qmkjCE1Vbu@tjmaciei-mobl2> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: ger.gmane.org 1390944529 5936 80.91.229.3 (28 Jan 2014 21:28:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 28 Jan 2014 21:28:49 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC5JHI7A7ALRBF6CUCLQKGQEVI4GTDY@isocpp.org Tue Jan 28 22:28:57 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ve0-f197.google.com ([209.85.128.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W8GDJ-00042p-8X for gclcip-std-proposals@m.gmane.org; Tue, 28 Jan 2014 22:28:57 +0100 Original-Received: by mail-ve0-f197.google.com with SMTP id oz11sf2246728veb.8 for ; Tue, 28 Jan 2014 13:28:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state: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=7DaDqipwmAfAT+VEVK65Y9Imo+gCe3NFvBiT28CVH3Q=; b=Epvh52dP/ofOHyvSwsSQ6/CvAgSL0nydm4z7wYvSk/4rID/rdTYsfCK/zQVSZZdETs tOor9TZ4RMnOHrkHQ3RhGc1i8i2YxgnSLJan97UbmI52RKqqaPbkmnhSbc9QW1etxl5y ZqAY3uixMQDQivfyZ3GFx2ngZBV7Yd05f9BlqjRdcFB/w7Kaz1+KKPkupFqE2npPXIDz 3YN7BZCn20ABB9pzlAWEhbozs8TW0lcCvSFawAJ9jfKWPvn/u8E1FJLtgn9l5k+bpN3w fGpteDRDO1VW9Kwz6fO1DkOfnZ+7DI3tPrKY6u16Qf7ri8N9yHRf4sYu01GsFH4r/ZF4 +dYw== X-Gm-Message-State: ALoCoQlqFOdGF35Pftt0/qwV/GTiW6bDAMiwN4/TpogHndtN0oTum6Dj8/485By3mS2OKOq8b0B+ X-Received: by 10.236.4.136 with SMTP id 8mr1156023yhj.21.1390944536326; Tue, 28 Jan 2014 13:28:56 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.27.119 with SMTP id 110ls2157374qgw.28.gmail; Tue, 28 Jan 2014 13:28:55 -0800 (PST) X-Received: by 10.140.109.228 with SMTP id l91mr5960186qgf.72.1390944535531; Tue, 28 Jan 2014 13:28:55 -0800 (PST) Original-Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [2607:f8b0:400d:c00::22b]) by mx.google.com with ESMTPS id g88si12309101qgf.176.2014.01.28.13.28.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 Jan 2014 13:28:55 -0800 (PST) Received-SPF: pass (google.com: domain of ville.voutilainen@gmail.com designates 2607:f8b0:400d:c00::22b as permitted sender) client-ip=2607:f8b0:400d:c00::22b; Original-Received: by mail-qa0-f43.google.com with SMTP id o15so1325611qap.30 for ; Tue, 28 Jan 2014 13:28:55 -0800 (PST) X-Received: by 10.229.213.194 with SMTP id gx2mr6336216qcb.16.1390944535429; Tue, 28 Jan 2014 13:28:55 -0800 (PST) Original-Received: by 10.224.49.65 with HTTP; Tue, 28 Jan 2014 13:28:55 -0800 (PST) In-Reply-To: X-Original-Sender: ville.voutilainen@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of ville.voutilainen@gmail.com designates 2607:f8b0:400d:c00::22b as permitted sender) smtp.mail=ville.voutilainen@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:8905 Archived-At: On 28 January 2014 20:49, Matthew Woehlke wrote: > On 2014-01-28 12:50, Ville Voutilainen wrote: >> I think it's beneficial to be able to do, in a fairly straightforward >> manner, things like >> auto h = foo.native_handle(); >> low_level_processing_func(h); > As low_level_processing_func is presumably already conditionally defined > depending on the platform, why would you not simply pass 'foo' to it > directly? (What if different implementations have multiple possible handles Because I'd rather not duplicate the code that extracts the native handle from foo. > that the user may need? What if an implementation supports multiple, > runtime-selectable engines with different handle types?) Then these handles need to be separately extracted from the native handle. That is, of course, not going to end up achieving the avoidance of boilerplate in the previous part. >> #if defined(PLATFORM_X) >> auto h = foo.get_native_handle_for_platform_x(); >> #elif defined(PLATFORM_Y) >> yadda yadda yadda >> #endif >> low_level_processing_func(h); // I do hope that the #else branch >> initialized a h... > If it didn't, would you not have also gotten a compile error in the above > version due to there being no appropriate overload (if there is a definition > at all) of low_level_processing_func? Sure, but I would've gotten that compiler error from code that looks remotely sane, rather than being a preprocessor mess. -- --- 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/. .