[Bug c++/30524] New: Template argument is not recognized as a Type inside a template function.
Perfectly valid C++ syntax causes a compiler error when used inside a template
function. Both the Sun compiler and Microsoft compiler have no trouble with the
sample code shown below. Notice that the same code inside the non-template
function succeeds in compiling just fine. The GCC compiler appears to have
trouble figuring out that the expression resolves into a normal data type. The
error I get from GCC is:
test23.cpp: In function `void THIS_FAILS(T)':
test23.cpp:19: error: type/value mismatch at argument 1 in template parameter
list for `templateclass T struct whatever'
test23.cpp:19: error: expected a type, got ` Ssizeof (func(var))::type'
test23.cpp:19: error: invalid type in declaration before ';' token
~
template typename T struct whatever {};
template int struct S;
template struct S1 { typedef char Array[ 1 ]; typedef char type; };
S1::Array func( const char );
void THIS_WORKS( char var )
{
whatever S sizeof( func( var ) ) ::typetemporary;
}
template typename T
void THIS_FAILS( T var )
{
whatever S sizeof( func( var ) ) ::typetemporary;
}
--
Summary: Template argument is not recognized as a Type inside a
template function.
Product: gcc
Version: 3.4.6
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: SSacek at appsecinc dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30524
[Bug c++/29378] New: The copy constructor is not being called upon return from function calls.
Functions returning objects do not call the copy constructors for permanent
objects. The program below works for the Solaris and Microsoft compilers, but
not for the GCC compiler.
Im using:
-bash-3.00$ gcc -v
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.6/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux
Thread model: posix gcc version 3.4.6 20060404 (Red Hat 3.4.6-3)
#include stdio.h
struct S
{
S(){ printf( Inside default constructor \n ); }
S( const S ) { printf( Inside copy constructor \n ); }
};
S f( void )
{
S s1;
return s1;
}
int main ( int, char ** )
{
S s1;
S s2( s1 ); // must call the copy constructor
S s3 = f(); // must call the copy constructor
S s4( f() ); // must call the copy constructor
return 0;
}
#if 0
// GCC output is:
Inside default constructor
Inside copy constructor
Inside default constructor
Inside default constructor
// Both Solaris and Microsoft output is:
Inside default constructor
Inside copy constructor
Inside default constructor
Inside copy constructor
Inside default constructor
Inside copy constructor
#endif
--
Summary: The copy constructor is not being called upon return
from function calls.
Product: gcc
Version: 3.4.6
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: SSacek at appsecinc dot com
GCC build triplet: gcc version 3.4.6
GCC host triplet: Red Hat 3.4.6-3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29378
[Bug c++/29378] The copy constructor is not being called upon return from function calls.
--- Comment #2 from SSacek at appsecinc dot com 2006-10-07 09:19 ---
Ok, I see that GCC has a work-around for this issue, but I must insist that the
GCC compiler is incorrect in its interpretation of the C++ standard for two
reasons.
1) Optimizations should be allowed for temporary objects only, but not for
named (permanent) objects. Example:
struct S{};
S foo()
{
return S; // this is an un-named temporary object
// optimizations allowed
}
S foo2()
{
S s1; // this is a named permanent object
return s1; // optimizations not allowed
}
The object in foo2() is permanent, and lives and dies in the scope of
function foo2(). Therefore, upon return, the copy constructor must be called,
as well as the destructor.
2) The second reason is that if GCC ignores the programmer written copy
constructors, then the program will be misbehaved, and the results
unpredictable, with even the possibility of a crash. Optimizations are
understandable only if they don't leave objects in unknown states.
The key question here is WHAT IS A TEMPORARY OBJECT ?
I am convinced that the GCC compiler has it wrong, and I have the Solaris and
Microsoft compilers to back me up on this.
Just how many C++ Standards are there?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29378
[Bug c++/25773] New: Preprocessor concatenation of forward-slash fails
The code below fails to preprocess correctly. Shouldn't it handle this simple
case correctly? VC++ produces the expected results.
#define COMMENT /##/
void main( void )
{
COMMENT this line should be commented out
}
--
Summary: Preprocessor concatenation of forward-slash fails
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: SSacek at appsecinc dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25773
[Bug c++/21903] Default argument of template function causes a compile-time error
--- Additional Comments From SSacek at appsecinc dot com 2005-06-04 18:28 --- I would like to thank you folks at gcc.gnu.org for taking a serious look at this issue. I wanted to write here a little bit about what I do and how this matter came to light. It is my occupation to write cross-platform applications that run on Linux, Solaris, and Windows operating systems. When I was developing my code, I started coding and compiling it on the Microsoft compiler first. I did not get any compiler errors from my code and was happy that it was correct. Then when I tried compiling it using GCC, I started getting the compile-time errors. My first instinct was to go back to my code and fix it. I usually do that because the Microsoft compiler isnt as strict about the C++ language as GCC is. But I stared at the code for about an hour and couldnt figure out what I was doing wrong. Based on the error message that GCC gave me, the default argument for parameter 1 has not yet been parsed, I concluded that this might be a rare case in which the GCC compiler got it wrong. I base that conclusion on the fact that the error message from GCC implies a sense of incompleteness in the class definition, and hence cannot generate object code. But the fact that the Microsoft compiler can begin generating code indicates that there is enough information there to begin instantiating the objects. I figured GCC should also be able to do the same with what was given. Here at AppSecInc, where I work, we also tried the same tests with the ICC compiler and got the same results that Andrew Pinski mentioned. That actually surprised me at first, but then I couldnt help but draw some conclusions about it. Intel is a hardware manufacturer, and not a compiler developer. I cant help but believe that Intel didnt want to re-invent the whole wheel, and therefore borrowed the open-source parser that the folks at GCC created. These opinions are solely my own. Thank you, -Sid Sacek -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21903
[Bug c++/21903] Default argument of template function causes a compile-time error
--- Additional Comments From SSacek at appsecinc dot com 2005-06-04 19:17
---
Dear Giovanni Bajo,
Thank you for that detailed explanation. Based on what you said, it sounds
like a complex problem to solve; however, it may not be as difficult as it
first appears. Take the example below, which was already shown to us by
Wolfgang Bangerth. Compile it, and GCC is happy. Then remove the comment from
line 5, and GCC becomes unhappy. Mysterious! With line 5 commented out, GCC
believes that everything is complete. But add line 5 back into the equation,
and GCC believes that things are now incomplete. The Derived structure is in
itself complete too, and judging by this behavior of GCC, my approach to
solving the mystery would be to find out why a class like struct Base, which
was once complete, changes its status to incomplete by merely adding
the Derived struct. Of course, Im assuming that the Base struct is being
parsed before the Derived struct.
Understanding the reason why the status change occurs should help in knowing
whether this is an easy or difficult thing to change.
Regards,
-Sid Sacek
struct O {
templatetypename T struct Base {
void set (T, bool=true);
};
// struct Derived : public Baseint {};
};
void x ()
{
O::Baseint b;
b.set(1);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21903
[Bug c++/21903] New: Default argument of template function causes a compile-time error
Compile the test program below using this command line:
g++ test.cpp
The code below fails to compile, and gives the following error message:
-bash-3.00$ g++ test.cpp
test.cpp: In member function `void Test::cell_test()':
test.cpp:36: error: the default argument for parameter 1 of `void
Test::Cell_baseType::set(Type, bool) [with Type = const char*]' has not yet
been parsed
class Test
{
protected:
template typename Type class Cell_base
{
protected:
boolm_relevance;
Typem_field;
public:
Cell_base (void)// the
constructor
: m_relevance( false ),
m_field( Type() )
{ }
// the setter
void set (Type value, bool relevance = true)
{
m_relevance = relevance;
m_field = value;
}
};
class Cell : public Cell_base const char *
{
};
public:
//--
// Test out the cell classes
//--
void cell_test (void)
{
Cell c;
c.set(To be or not to be \n\n );
}
};
//--
// Main - program entry
//--
int main (int argc, char **argv)
{
Test t;
t.cell_test();
return 0;
}
--
Summary: Default argument of template function causes a compile-
time error
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: SSacek at appsecinc dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21903
