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
