This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Possible range based 'for' bug
- From: Julian Klappenbach <jklappenbach at gmail dot com>
- To: gcc at gcc dot gnu dot org
- Date: Sun, 21 Jun 2015 08:56:10 -0700
- Subject: Re: Possible range based 'for' bug
- Authentication-results: sourceware.org; auth=none
- References: <CAJ49vaUdYycmCPFEhCmJ9uSAzj2pCdp8oRC=yx1NSG1yZgNExA at mail dot gmail dot com>
Version info:
Configured with:
--prefix=/Applications/Xcode.app/Contents/Developer/usr
--with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
Target: x86_64-apple-darwin14.3.0
Thread model: posix
I'm using the default build provided by brew. If you need more
information, I'd be happy to provide it.
The issue:
I've been working on a new framework library, and with iterators that
would be able to take advantage of c++'s range-based for loop. The
API requires that I adhere to std's iterators, supporting begin and
end, as well as ++ and * operators.
Since I have many different types of iterators, I had created a basic
interface to pass them around, an abstract virtual class with pure
virtual members. The problem occurs when the logic behind the range
based for loop calls begin, and receives the pure virtual base class
of the iterator. This causes the compiler error:
../src/ListTests.cpp:156:13: error: variable type 'Iterable<int>' is
an abstract class
for (int x : aList.values()) {
Would it be possible for the logic in the ranged-for loop to check for
a v-table, and execute polymorphic calls? If not, there are
mitigating (non-ideal) strategies that I could use. However, I
thought it would be worth asking, and if this is deemed a bug, go
through the effort of posting an entry to bug tracker.
Thanks for your time,
Julian