Re: Possible range based 'for' bug
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' 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
Re: Possible range based 'for' bug
On 21 June 2015 at 16:56, Julian Klappenbach wrote: > 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 You're not using GCC, you're using LLVM. Even if you were using GCC "is this a bug?" questions are off-topic on this list, they belong in the Bugzilla bug tracker or the gcc-help mailing list, not here. > 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' is > an abstract class It sounds like your begin() function is declared to return an abstract class by value, that is not possible in C++. THis has nothign to do with range-based for, you just can't return an abstract class type from a function.
Re: Possible range based 'for' bug
The issue occurred to me after I sent the email. begin() / end() return iterators by value, not reference. So, you're correct in identifying the value / reference issue. But to be precise: you can't return an abstract class type *by value* from a function. If the return values of begin() / end() were returned and accepted as a reference, then I believe this would work. This difference is that return by value results in an implicit instantiation, which would attempt to create the abstract type. Given that the existing libs all are coded to return iterators by value from begin() / end(), I would assume that converting the range-for logic to work with references would cause some nasty side-effects. Pity. On Sun, Jun 21, 2015 at 10:49 AM, Jonathan Wakely wrote: > On 21 June 2015 at 16:56, Julian Klappenbach wrote: >> 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 > > You're not using GCC, you're using LLVM. > > Even if you were using GCC "is this a bug?" questions are off-topic on > this list, they belong in the Bugzilla bug tracker or the gcc-help > mailing list, not here. > >> 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' is >> an abstract class > > It sounds like your begin() function is declared to return an abstract > class by value, that is not possible in C++. THis has nothign to do > with range-based for, you just can't return an abstract class type > from a function.
Re: Possible range based 'for' bug
On 21 June 2015 at 19:16, Julian Klappenbach wrote: > The issue occurred to me after I sent the email. > > begin() / end() return iterators by value, not reference. > > So, you're correct in identifying the value / reference issue. But to > be precise: you can't return an abstract class type *by value* from a > function. I was already being precise when I said you can't return an abstract class type from a function. If you return by reference you are not returning a class type, you are returning a reference type :-) > If the return values of begin() / end() were returned and > accepted as a reference, then I believe this would work. This > difference is that return by value results in an implicit > instantiation, which would attempt to create the > abstract type. > > Given that the existing libs all are coded to return iterators by > value from begin() / end(), I would assume that converting the > range-for logic to work with references would cause some nasty > side-effects. That is not an option, the standard is very explicit about the behaviour of range-based for, and whatever begin() returns is copied by value, so still wouldn't work with abstract classes even if you changed your begin() to return a reference. See http://en.cppreference.com/w/cpp/language/range-for And this is still off-topic on this list.
gcc-6-20150621 is now available
Snapshot gcc-6-20150621 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/6-20150621/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 224713 You'll find: gcc-6-20150621.tar.bz2 Complete GCC MD5=8f988c8c585fd6c0fba2a83ca6357c8f SHA1=5f9cee10489b498219c9353474f31fb05b1c8cfe Diffs from 6-20150614 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
set_src_cost lying comment
set_src_cost says it is supposed to /* Return the cost of moving X into a register, relative to the cost of a register move. SPEED_P is true if optimizing for speed rather than size. */ Now, set_src_cost of a register move (set (reg1) (reg2)), is zero. Why? Well, set_src_cost is used just on the right hand side of a SET, so the cost is that of (reg2), which is zero according to rtlanal.c rtx_cost. targetm.rtx_costs doesn't get a chance to modify this. Now consider (set (reg1) (ior (reg2) (reg3))), for which set_src_cost on rs6000 currently returns COSTS_N_INSNS(1). It seems to me that this also ought to return zero, if the set_src_cost comment is to be believed. I'd claim the right hand side of this expression costs the same as a register move. A register move machine insn "mr reg1,reg2" is encoded as "or reg1,reg2,reg2" on rs6000! Continuing in the same vein, an AND is no more expensive than an IOR, and similarly for other ALU operations. So they all ought to cost zero?? But this is ridiculous since set_src_cost is used as in many places as the cost of an entire insn, eg. synth_mult compares the cost of implementing a multiply as a series of adds and shifts against the cost of a multiply. If all those adds and shifts are costed at zero, then synth_mult can't do its job. So what should that comment say? -- Alan Modra Australia Development Lab, IBM
