[Bug 45770] (c++) New: global access allowance exceeds that of derived class

[MichieldeB at aim dot com]

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

   Summary: global access allowance exceeds that of derived class
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: michiel...@aim.com


// g++ (Ubuntu 4.4.3-4ubuntu5) 4.4.3
// Copyright (C) 2009 Free Software Foundation, Inc.
// This is free software; see the source for copying conditions.  There is NO
// warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

class A
{

friend class B;

public:
  A(int i) { a = i; }

private:
  A() { a = 0; }
  int a;

};

class B : private A // making protected will eliminate the below problem
{

public:
  B(int i) : A () { a = i >> 1; b = i & 1; }

private:
  bool b;

};

class C : public B
{

public:
  C() : B(4) { A foo(3); } // functions of B may not have local variables A

}; 

main () { A bar(3); } // main may have local variables A

-- 
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug c++/45770] global access allowance exceeds that of derived class

[MichieldeB at aim dot com]

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

MichieldeB at aim dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |

--- Comment #2 from MichieldeB at aim dot com 2010-09-24 21:53:56 UTC ---
// If the access of locals should be inherited, then the following is a bug.

// g++ (Ubuntu 4.4.3-4ubuntu5) 4.4.3
// Copyright (C) 2009 Free Software Foundation, Inc.
// This is free software; see the source for copying conditions.  There is NO
// warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

class A
{

friend class B;

public:
  A(int i) { a = i; }

private:
  A() { a = 0; }
  int a;

};

class B : private A // making protected will allow local variables A below
{

public:
  B(int i) : A () { a = i >> 1; b = i & 1; }

private:
  bool b;

};

class C : public B
{

public:
  C() : B(4) { ::A foo(3); } // functions of B may have local variables ::A
 // but not A
}; 

template  class D : private T
{
  D(int i) : T(i) { U u; } 
};  

template class D; // local A gets global access rights

main () { ::A bar(3); } // main may have local variables A

-- 
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug c++/45770] global access allowance exceeds that of derived class

[MichieldeB at aim dot com]

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

MichieldeB at aim dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |

--- Comment #4 from MichieldeB at aim dot com 2010-09-26 18:14:26 UTC ---
My last counterexample was invalid, sorry. Furthermore, the problem does not
seem a template problem. I now have an example where the local object has lower
rights than the inherited object, thus no access inheritance for the local.

// g++ (Ubuntu 4.4.3-4ubuntu5) 4.4.3
// Copyright (C) 2009 Free Software Foundation, Inc.
// This is free software; see the source for copying conditions.  There is NO
// warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

class A
{

friend class B;

public:
  A(int i) { a = i; }

protected:
  A(int i, int j) { a = i ^ j; }

private:
  A() { a = 0; }
  int a;

};

class B : private A // making protected will allow local variables A below
{

public:
  B(int i) : A () { a = i >> 1; b = i & 1; }

private:
  bool b;

};

class C : public B
{

public:
  C() : B(4) { ::A foo(3); } // functions of B may have local variables ::A
 // but not A
};

class D : public A
{
  friend class D;

  D(int i, int j) : A(i,j) 
  { 
A d(i,j); // friend class D of class D has no inherited rights here
  // note that friends do not have inherited objects in general
  }  
};  

main () { A bar(3); } // main may have local variables A

[Bug c/45831] New: 0 = 10 (with -O0, 0 = 0 with -O1, but 10 = 10 expected)

[MichieldeB at aim dot com]

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

   Summary: 0 = 10 (with -O0, 0 = 0 with -O1, but 10 = 10
expected)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: michiel...@aim.com


gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

#include 

main () {
  int ten = 10;
  printf ("%d = %d\n", 10 << -32, ten << -32);
  return 0;
}

[Bug c/45831] 0 = 10 (with -O0, 0 = 0 with -O1, but 10 = 10 expected)

[MichieldeB at aim dot com]

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

--- Comment #2 from Michiel  2010-09-29 14:20:29 UTC 
---
That does not mean that it is a very bad idea to use another library for
precomputation.

[Bug c/45831] 0 = 10 (with -O0, 0 = 0 with -O1, but 10 = 10 expected)

[MichieldeB at aim dot com]

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

--- Comment #3 from Michiel  2010-09-29 14:22:39 UTC 
---
Still it is a very bad idea to use another library for precomputation.

[Bug c/45831] 0 = 10 (with -O0, 0 = 0 with -O1, but 10 = 10 expected)

[MichieldeB at aim dot com]

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

--- Comment #4 from Michiel  2010-09-29 14:29:54 UTC 
---
In case you are missing the point, most non-bug posters compile on their target
machine.

[Bug c/45831] 0 = 10 (with -O0, 0 = 0 with -O1, but 10 = 10 expected)

[MichieldeB at aim dot com]

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

--- Comment #6 from Michiel  2010-09-29 15:19:11 UTC 
---
If undefined behavior only depends on the machine (most times compiling machine
and target machine are the same), then there will be less bias here.

[Bug c/45831] 0 = 10 (with -O0, 0 = 0 with -O1, but 10 = 10 expected)

[MichieldeB at aim dot com]

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

--- Comment #10 from Michiel  2010-09-30 11:23:58 
UTC ---
To get to know what a formula does, I usually compute some examples. When doing
so, I was warned, but ignored them and that was stupid.

There are however also warnings that are stupid. I now think of setting an
integer to -2147483648. 2147483648 is too large for an integer and it is good
that the compiler warns you. Unfortunately, the compiler ignores the context of
2147483648 and thus warns for -2147483648 as well. A similar argument applies
for setting an unsigned to a value in the range 2147483648 to 4294967295. 

On the other hand, setting an unsigned to a negative value does not give any
warning. Setting an unsigned to e.g. -1 is totally unnecessary, since you can
write ~0 instead, which is also preferable.

[Bug c/45831] 0 = 10 (with -O0, 0 = 0 with -O1, but 10 = 10 expected)

[MichieldeB at aim dot com]

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

--- Comment #14 from Michiel  2010-09-30 18:30:16 
UTC ---
Remove signed/unsigned warnings, or even overflow warnings, for constants that
are used in an expression with the following operations only:

casts to integral type of smaller or equal size,
casts to boolean, !, == and !=,
casts from boolean to integral type, ? :,
+ - * << & | ^.

Probably I missed some, but I hope you see what I mean. Then you will
understand that /, %, >> and casts to larger integral type (or float, double)
do not belong to this list.

Is that really too hard?

[Bug c/45831] 0 = 10 (with -O0, 0 = 0 with -O1, but 10 = 10 expected)

[MichieldeB at aim dot com]

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

--- Comment #16 from Michiel  2010-09-30 19:38:55 
UTC ---
(In reply to comment #15)
> (In reply to comment #14)
> >
> > Is that really too hard?
>
> You are ignoring everything everybody is saying. If you think it is trivial,
> just take one single little case of the ones that bother you and fix it:
> 
> http://gcc.gnu.org/contribute.html
> 
> GCC needs more developers anyway, so you are welcome on board.

I am not ignoring everyone, since I formulated things far more concrete than
before. And I failed to formulate similar things to warnings for assigning
negative expressions to unsigned integers.

Another thing that is worth noting, is that recognizing expression as mentioned
above is also valuable for optimization, namely if you convert the result later
to a smaller integral type, and the larger integral type is larger than the
machines integral type, then you better do the computations with the smaller
integral type instead.

I have to apologize. There are already too many technically interesting things,
or just interesting things that are also technically, that I want to do.
Furthermore, I think that it will take very much time before I can make my
first contribution to the compiler, but I should browse the source to get a
better opinion on that. Some library routines would be more attainable, I will
think about that.

[Bug c++/45942] New: class will not get friends with another class

[MichieldeB at aim dot com]

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

   Summary: class will not get friends with another class
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: michiel...@aim.com


In my current project, the construction of template class classB works well
when friend class declarations are replaced by making classA public.

With attempt 1, the compiler gives an error message, but not before
instantiation.

With attempt 2, the compiler gives an error message immediately, but an
incorrect one.


g++ (GCC) 4.4.1 20090725 (Red Hat 4.4.1-2)
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


template  class classA;

template  &instanceA> class classB;

template  class classA
{

  // error message on instantiation: too few template parameters (1 < 3)
  template  friend class classB;

  // incorrect error message: partial specialization claimed but not apparent 
  // template  friend class classB;

private:
  int for_use_by_classB;

};

template  &instanceA> class classB
{

  classB (int i) { instanceA.for_use_by_classB = i; }

};

// instantiation
// template class classA;

[Bug c++/45942] class will not get friends with another class

[MichieldeB at aim dot com]

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

--- Comment #3 from Michiel  2010-10-08 14:51:36 UTC 
---
(In reply to comment #1)
> It's not entirely clear what you're saying is a bug, because your testcase
> doesn't give any error.
> 
> It's more helpful to provide the source code that you claim produces the bug. 
> I assume you this:
> 
> template  class classA;
> 
> template  &instanceA> class classB;
> 
> template  class classA
> {
>   // incorrect error message: partial specialization claimed but not apparent 
>   template  friend class classB;
> 
> private:
>   int for_use_by_classB;
> 
> };
> 
> template  &instanceA> class classB
> {
> 
>   classB (int i) { instanceA.for_use_by_classB = i; }
> 
> };
> 
> // instantiation
> template class classA;
> 
> 
> That code is not valid, the error is not incorrect.
> 
> You have declared classB as a friend, and as a template with one template
> parameter, instanceA, and the template arguments . That is a
> partial specialization.

Apparently you are making the same mistake as the compiler. In the friend class
declaration, the third parameter is not free, indeed, but its specialization
level does not exceed that of the class definition of class classB. Thus the
friend declaration is no specialization in the proper relative sense. 

If you still do not agree, just provide code that makes classB a friend of
classA. That is what I want.

[Bug c++/45942] class will not get friends with another class

[MichieldeB at aim dot com]

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

Michiel  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |

--- Comment #4 from Michiel  2010-10-08 14:58:42 UTC 
---
(In reply to comment #2)
> This variation uses B1 for your first attempt and B2 for your second attempt.
> 
> template  class A;
> 
> template  &a> class B1;
> 
> template  &a> class B2;
> 
> template  class A
> {
>   template  friend class B1;
> 
>   template  friend class B2;
> };
> 
> // instantiation
> template class A;
> 
> 
> This code is not valid, G++ is correct to reject it.

Please explain why the code is invalid, and do not click "Resolved invalid"
until ClassB is a friend of ClassA.

[Bug c++/45942] class will not get friends with another class

[MichieldeB at aim dot com]

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

--- Comment #7 from Michiel  2010-10-08 15:12:36 UTC 
---
(In reply to comment #5)
> (In reply to comment #3)
> > Apparently you are making the same mistake as the compiler.
> 
> Before adjusting the sentence to use a proper plural here (the same error
> happens with the Intel, EDG, Comeau, SunStudio and Microsoft compilers, for
> sure) I would suggest considering a little longer the first person singular.

Does C++ accept dependencies between template parameters. G++ does that within
my project. And all I am asking is to make ClassB a friend of ClassA before
clicking "Resolved Invalid". I am using G++ and do not see a reason why another
compiler should be able to make ClassB a friend of ClassA.

[Bug c++/45942] class will not get friends with another class

[MichieldeB at aim dot com]

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

--- Comment #9 from Michiel  2010-10-08 15:43:13 UTC 
---
(In reply to comment #6)
> (In reply to comment #4)
> > (In reply to comment #2)
> > > This code is not valid, G++ is correct to reject it.
> > 
> > Please explain why the code is invalid, and do not click "Resolved invalid"
> > until ClassB is a friend of ClassA.
> 
> You reported an invalid bug, so I rejected it.
> It's not my job to teach you C++ but here you go:
> 
> template  class A;
> 
> template  &a> class B;
> 
> template  class A
> {
>   template &> friend class B;
> };
> 
> 
> That makes B&> a friend of A
> 
> Your original example is invalid for the reason the compiler gave, the syntax
> you tried to use declares a partial specialization, which is not allowed in a
> friend declaration.  That's how C++ works, I don't make the rules.

I really tried everything, but I have to admit I missed that one. Sorry. But
you have to admit that it is a rather unnatural way to make friends. 
Furthermore, the third parameter Z is missing (I would prefer A&Z), but
that does not seem to be a problem for the compiler.

Thus it seems that the bug is that c++ is designed is such a way that it gives
error messages which are incorrect.

If you would have followed the title of my bug report immediately instead of
saying that is was invalid, then the discussion would have been unnecessary.

Now it is still odd that the first attempt gives an error so lately. The
template precompiler counts three arguments and the template instantiator
counts one, which is not very consistent.

[Bug c++/45942] class will not get friends with another class

[MichieldeB at aim dot com]

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

--- Comment #11 from Michiel  2010-10-08 16:09:33 
UTC ---
C++ is designed to give an error message which is syntactically correct, but
semantically incorrect.

I thought that the template prechecker (preprocessor or whatever, do not
correct me this time) counted template arguments in friend declarations, but
now it seems it does not, sorry.

[Bug c++/45942] class will not get friends with another class

[MichieldeB at aim dot com]

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

--- Comment #12 from Michiel  2010-10-09 13:02:51 
UTC ---
> You seem to misunderstand what this bugzilla is for. 

No, that is not true, although the effect has been equally terrible. Indeed,
you only need to say that my bug is invalid.

However, it is common in many forms of written communication that one assures
him/herself that the other has read and understood everything. Maybe I should
have assumed that this was the case, but reacting on one out of three issues in
my bug report was not very convincing in this matter.

[Bug c++/45942] class will not get friends with another class

[MichieldeB at aim dot com]

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

--- Comment #13 from Michiel  2010-10-09 13:38:05 
UTC ---
The reason that I did not succeed in making ClassB a friend of ClassA is that
C++ is not very logical. See below.


template  class classB;
template  class classC;

template  class classA
{

  // classA does NOT become friends with classA
  friend class classB;

  // with an extra template argument, this is only possible via 
  // specialization, which is not allowed
  template <> friend class classB;
  template  friend class classC;

  // because with your solution, classA (classB)
  // DOES become friends with classA (classB)
  template  friend class classB;
  template  friend class classC;

};

template class classA;