Re: wishlist: support for shorter pointers

["Rafał Pietrak" <embedded@ztk-rp.eu>]

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<typename Iter>
> 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<typename Iter>
> 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