From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sm.strop.com.pl (sm.strop.com.pl [83.17.179.219]) by sourceware.org (Postfix) with ESMTPS id 63F6B3858D3C for ; Wed, 28 Jun 2023 10:46:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 63F6B3858D3C Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=ztk-rp.eu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=ztk-rp.eu Received: from zorro.ztk-rp.eu ([::ffff:10.208.4.171]) (TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by sm.strop.com.pl with ESMTPS; Wed, 28 Jun 2023 12:43:39 +0200 id 0000000003CACA28.00000000649C0EDB.00006375 Received: from public-gprs403814.centertel.pl ([37.47.208.167]:5107 helo=[192.168.43.32]) by zorro.ztk-rp.eu with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qESeA-00Ca3c-50; Wed, 28 Jun 2023 12:43:39 +0200 Message-ID: <9bf8d93d-7342-ad21-4f06-864978e580f4@ztk-rp.eu> Date: Wed, 28 Jun 2023 12:43:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Content-Language: en-US To: waffl3x Cc: Jonathan Wakely , "gcc@gcc.gnu.org" References: <439affd4-11fe-de80-94c8-6fc64cbf76ec@ztk-rp.eu> <21650b1b-1d2e-7929-3105-b8aaca629272@ztk-rp.eu> From: =?UTF-8?Q?Rafa=c5=82_Pietrak?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 37.47.208.167 X-SA-Exim-Mail-From: embedded@ztk-rp.eu X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,NICE_REPLY_A,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,T_SPF_HELO_PERMERROR autolearn=ham autolearn_force=no version=3.4.6 Subject: Re: wishlist: support for shorter pointers X-SA-Exim-Version: 4.2.1 (built Sat, 13 Feb 2021 17:57:42 +0000) X-SA-Exim-Scanned: Yes (on zorro.ztk-rp.eu) Received-SPF: unknown (IP address lookup failed.) SPF=FROM; sender=embedded@ztk-rp.eu; remoteip=::ffff:10.208.4.171; remotehost=; helo=zorro.ztk-rp.eu; receiver=sm.strop.com.pl; List-Id: Hi Alex, W dniu 28.06.2023 o 11:56, waffl3x pisze: > Here's a quick and dirty example of how this function could be rewritten with > modern C++. I omitted some necessary details, particularly the implementation of the > linked list iterator. I also wrote it out quickly so I can't be certain it's 100% > correct, but it should give you an idea of whats possible. trying.... > > // I assume you meant to return a pointer > template > auto test_funct(Iter iter, Iter end, char opt) { > for (; iter != end; ++iter) { > // dereferencing iter would get buff > if (!*iter) { *iter = opt; break; } > } > return iter; > } -------------------------- TEST.CPP is the above code $ g++ -fpermissive -c test.cpp >>no error, GOOD :) $ g++ -fpermissive -S test.cpp $ cat test.s .file "test.cpp" .text .ident "GCC: (Debian 12.2.0-14) 12.2.0" .section .note.GNU-stack,"",@progbits ---------------end-of-file---------- Hmm... that's disappointing :( nothing was generated. then again. I've noticed that you've changed pointers to indices. I've pondered that for my implementation too but discarded the idea for it will require adjustments by struct-size (array element size) on every access.... Or may be C++ does a different thing with [object++], then what plain-c does with [variable++]? I's hard to analyze code without basic knowledge of the language :( > > I also made an example using the C++ algorithms library. > > template > auto test_funct(Iter begin, Iter end, char opt) { > auto iter = std::find_if(begin, end, [](auto buff){return !buff;}); > if (iter) { > *iter = opt; > } > return iter; > } here I got: test2.cpp:3:22: error: ‘find_if’ is not a member of ‘std’ so, it's a nogo for me either. > As I said, there's quite a bit omitted here, to be blunt, implementing both > the fancy pointers (especially when I don't know anything about the hardware) and > the iterators required would be more of a task than I am willing to do. I'm happy > to help but I don't think I should be doing unpaid labor :). Fair enough. [---------] > > I'm happy to answer more questions and help, however I'm concerned this is > getting fairly unrelated to GCC. From my perspective it is related to GCC (well... ok, to CC in general - it "smells" like an extention to "C-standard" providing additional "funny" semantics to CC. But GCC is a "front-runner" for CC evolution, right? :). Then again. I'm not into drawing anybody into unfruitful and pointless support (for my little project). I only hoped that the problem could be recognized and may be would inspire some developers out there (as it would be silly for me, if I thought its implementation into GCC could happen before my small project ends, right?). Anyway, thanx for the hints and suggestions. -R