[Bug c++/32402] Error while allocating array of pointers to objects of a pure virtual class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402 Paolo Carlini changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org| --- Comment #14 from Paolo Carlini --- The parser gets confused when in cp_parser_new_expression it tries first a cp_parser_new_placement: the bogus error is produced as part of that. As a parenthesized type-id, 'pure (*[3])' is normally accepted.
[Bug c++/32402] Error while allocating array of pointers to objects of a pure virtual class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402 --- Comment #13 from Jonathan Wakely 2010-10-31 12:42:00 UTC --- (In reply to comment #12) > > I m sure this IS a bug , and I cant understand why this (documented) bug is > still new 3 years later. It's a bug, and should be fixed, but it's not critical and workaround is available. > I m not sure this is ok with C++ grammar or semantic ( but I think it is ), I > m just sure this is a good thing to give microsoft and concurrent compilers > more customers who will not have the choice to move to linux/gcc. No need to exaggerate - simpler syntax can be used and the code will compile - this bug should not prevent anyone using GCC, claiming it does is silly. > Even if its not a bug, gcc should provide an "official" workaround and argue > on WHY this is not possible in gcc, while available without any problem with > most other compilers . There's a workaround in comment 5, it's been there for 3 years.
[Bug c++/32402] Error while allocating array of pointers to objects of a pure virtual class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402 --- Comment #12 from William Waisse 2010-10-31 11:59:13 UTC --- I m no more working for the company that was trying to port this code to linux/GCC 3 YEARS AGO . They finally abandonned the idea to get their professional application working on GCC/Linux. I m sure this IS a bug , and I cant understand why this (documented) bug is still new 3 years later. I m not sure this is ok with C++ grammar or semantic ( but I think it is ), I m just sure this is a good thing to give microsoft and concurrent compilers more customers who will not have the choice to move to linux/gcc. Even if its not a bug, gcc should provide an "official" workaround and argue on WHY this is not possible in gcc, while available without any problem with most other compilers . Thanks Jonathan Wakely ( comment #9 ) , posting a workaround IS relevant, and useful for the next one hitting this bug.
[Bug c++/32402] Error while allocating array of pointers to objects of a pure virtual class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402 --- Comment #11 from Jonathan Wakely 2010-10-31 11:31:01 UTC --- (In reply to comment #10) > Ok, I've read the bug report following a report from a friend, and after > checking various sources I've come to the following conclusion: > > new pure(*[3]) is not valid That's not what the bug report contains though! It's "new (pure(*[3]))" with an extra set of parentheses around the type, so according to the grammar "pure(*[3])" must be parsed as a type-id, there is no initializer > When parsed, "new pure(*[3])" is parsed as "new instance of class pure with > parameter *[3]". Right, and it's not accepted, see comment 5: > - "list = new pure(*[3]);" => does not compile But that's a different case to "new (pure(*[3]))" which is what this PR is about. > Anyway I see no logical reason why one would want to put part of its > allocation > into parenthesis. > > "new pure*[3]" should be perfectly acceptable, is easier to read, and is > accepted by GCC without problems. That's beside the point, if the grammar is valid then it should be accepted. > Jonathan Wakely's example with decltype() is non related as decltype() is a > new > compiler keyword, which is valid in this context, but has nothing to do with > the original problem. It demonstrates that GCC is happy to allocate an array of pure* using different syntax, and that the syntax works for declaring an automatic variable. > Anyway I believe this bug report should be closed before more people spend > time looking at C++ references for this. I disagree, it's a bug, and the code is accepted by other compilers.
[Bug c++/32402] Error while allocating array of pointers to objects of a pure virtual class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402 Mark Karpeles changed: What|Removed |Added CC||mark at tibanne dot com --- Comment #10 from Mark Karpeles 2010-10-31 07:34:09 UTC --- Ok, I've read the bug report following a report from a friend, and after checking various sources I've come to the following conclusion: new pure(*[3]) is not valid When parsed, "new pure(*[3])" is parsed as "new instance of class pure with parameter *[3]". Anyway I see no logical reason why one would want to put part of its allocation into parenthesis. "new pure*[3]" should be perfectly acceptable, is easier to read, and is accepted by GCC without problems. Jonathan Wakely's example with decltype() is non related as decltype() is a new compiler keyword, which is valid in this context, but has nothing to do with the original problem. Anyway I believe this bug report should be closed before more people spend time looking at C++ references for this.
[Bug c++/32402] Error while allocating array of pointers to objects of a pure virtual class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402
--- Comment #9 from Jonathan Wakely 2010-10-30
11:46:47 UTC ---
As an extra data point, this compiles with -std=c++0x
struct pure;
void f()
{
pure (*arr[3]);
pure** p = new (decltype(arr));
delete[] p;
}
This shows that allocating an array of pure* is semantically OK, it's just a
bug in parsing or checking the new-expression.
[Bug c++/32402] Error while allocating array of pointers to objects of a pure virtual class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2010.10.28 17:44:04 Ever Confirmed|0 |1 --- Comment #8 from Jonathan Wakely 2010-10-28 17:44:04 UTC --- I'm going to stick my neck out and confirm this, I think it should compile. The new-expression creates an object of type "array of pointer to pure" and that is a complete type, whether pure is complete or abstract is not relevant.
[Bug c++/32402] Error while allocating array of pointers to objects of a pure virtual class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402
--- Comment #7 from Jonathan Wakely 2010-10-28
17:30:28 UTC ---
It doesn't depend on abstract types, this fails, even though it should be able
to declare an array of pure* without seeing the definition of pure:
struct pure;
void f()
{
pure** p = new (pure (*[3]));
}
I think the type-id is parsed correctly (it's fine to use it as a function
parameter, for example) but something checking the semantics of the
new-expression is wrong.
[Bug c++/32402] Error while allocating array of pointers to objects of a pure virtual class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402 --- Comment #6 from Jonathan Wakely 2010-10-28 17:21:03 UTC --- (N.B. this now gets the bogus warning from PR 46159) Grammatically: new (pure (*[3])); is a new-expression, with type-id "pure(*[3])" that type-id has type-specifier-seq "pure" and abstract-declarator "(*[3])" that abstract-declarator is a direct-abstract-declarator, with an abstract-declarator of "*[3]" which is a ptr-operator and an abstract-declarator of "[3]" So I think it's syntactically valid
[Bug c++/32402] Error while allocating array of pointers to objects of a pure virtual class
--- Comment #5 from p dot vestjens at gmail dot com 2007-11-13 13:38 --- Okay. First of all the code causing the problems isn't actually my own code. It is used in the Connexis middleware layer of IBM's Rational Rose Real-Time application. The reproduce.cpp file was created by IBM's support department to reproduce the problem. They claim that the file compiles with the GNU 3.2 compiler but not with the GNU 3.4.4 and 4.1.0 compilers. I'm using GNU 4.1.1 which also doesn't compile the code, but WindRiver's Tornado 2 GNU 2.7.2 and the MS Visual Studio 6 compiler do. The problem seems to lie in the abundant use of parentheses: - "list = new (pure(*[3]));" => does not compile - "list = new (pure*[3]);" => compiles - "list = new pure(*[3]);" => does not compile - "list = new pure*[3];" => compiles So, the only question still relevant to me is whether the original construction is valid C++ code according to the ISO C++ standard. I tried verifying this using the grammar printed in Stroustrup's "C++ Programming language (third edition" but did not quite succeed. I guess grammatically it is ok, but semantically the GCC compiler interprets the construction differently from its previous version(s). How do we determine if the original construction is correct, both grammatically and semantically? If it isn't valid, IBM should fix their code. If it is, there might be a bug in GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402
[Bug c++/32402] Error while allocating array of pointers to objects of a pure virtual class
--- Comment #4 from zackw at panix dot com 2007-11-12 19:41 --- I am no C++ expert, so I don't know what new pure (*[3]) actually means, but I am nearly certain it does *not* mean "allocate an array of 3 pointers to type pure". That would be new pure *[3] without the parentheses. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402
[Bug c++/32402] Error while allocating array of pointers to objects of a pure virtual class
--- Comment #3 from gcc at waisse dot org 2007-11-12 15:42 --- My problem is exactly the same as the one shown in the example code posted by Patrick Vestjens, all of the pure functions are re-implemented in the inherithing clas, so the inheriting class is no more pure but its still impossible to build. Why is this bug not confirmed since 2007-06-19 ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402
[Bug c++/32402] Error while allocating array of pointers to objects of a pure virtual class
--- Comment #2 from gcc at waisse dot org 2007-11-12 15:06 --- same kind of problem here, I'm currently porting an application from PGI/MFC to gcc/QT and I'm not able to build this code with the error message : /opt/cimlib/gcc_scali/AssembleurLocalPetsc.h:49: error: cannot allocate an object of abstract type CimSystemeLineaire::ALPetscPar /opt/cimlib/gcc_scali/AssembleurLocalPetsc.h:33: note: because the following virtual functions are pure within CimSystemeLineaire::ALPetscPar: /opt/cimlib/gcc_scali/AssembleurLocal.h:36: note: virtual CIMint CimSystemeLineaire::AssembleurLocal::ajout_contributions_matrice(CIMint, CIMint*, CIMint*, CIMdouble*) /opt/cimlib/gcc_scali/AssembleurLocal.h:70: note: virtual CIMint CimSystemeLineaire::AssembleurLocal::ajout_contributions_second_membre(CIMint, CIMint*, CIMdouble*) This happens with a create() method returning a new object, depending on the implementation of the abstract class ( some kind of virtual creator with a differnt code for each implementation ). -- gcc at waisse dot org changed: What|Removed |Added CC||gcc at waisse dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402
[Bug c++/32402] Error while allocating array of pointers to objects of a pure virtual class
--- Comment #1 from p dot vestjens at gmail dot com 2007-06-19 14:47 --- Created an attachment (id=13736) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13736&action=view) Sourcefile demonstrating the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402
