[Bug c++/32402] Error while allocating array of pointers to objects of a pure virtual class

[Bug c++/32402] Error while allocating array of pointers to objects of a pure virtual class

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> 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

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> 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

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402

Jonathan Wakely <redi at gcc dot gnu.org> 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 <redi at gcc dot gnu.org> 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

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402

--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> 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

[mark at tibanne dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402

Mark Karpeles <mark at tibanne dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mark at tibanne dot com

--- Comment #10 from Mark Karpeles <mark at tibanne dot com> 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

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402

--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> 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

[gcc at waisse dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402

--- Comment #12 from William Waisse <gcc at waisse dot org> 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

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402

--- Comment #13 from Jonathan Wakely <redi at gcc dot gnu.org> 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

[paolo.carlini at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|gcc-bugs at gcc dot gnu.org        |

--- Comment #14 from Paolo Carlini <paolo.carlini at oracle dot com> ---
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

[p dot vestjens at gmail dot com]

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

[zackw at panix dot com]

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

[gcc at waisse dot org]

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

[gcc at waisse dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1327 bytes --]



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

[p dot vestjens at gmail dot com]

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