Path: utzoo!utgpu!watmath!iuvax!cica!tut.cis.ohio-state.edu!cs.brown.edu!hps
From: hps@cs.brown.edu
Newsgroups: gnu.g++.bug
Subject: Conversion temporaries problem?
Message-ID: <8910261940.AA06829@benefit.cs.brown.edu>
Date: 26 Oct 89 19:40:47 GMT
Sender: daemon@tut.cis.ohio-state.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 60

given following input file (different header file for g++)

#include <stream.h>
#include <string.h>
struct string {
  char* p;
  int size; // of vec pointed to by p

  string(int sz) { p = new char[size=sz]; cout<<"string(int) ctor\n";}

  string(char* a) {p = new char[size=strlen(a)+1]; strcpy(p,a);
                     cout << "string(char*) ctor\n"; }
 
  ~string(){delete p; cout << "~string() dtor\n";}

  operator char*() {char* a = new char[size]; strcpy(a,p);
                      cout << "string::operator char*()\n"; return a;}
};

main()
{
char* a="Hello world"; 
string b="This is a string";
b=a=b=a;
}

CC 2.0 produces this output:

string(char*) ctor
string(char*) ctor
string::operator char*()
string(char*) ctor
~string() dtor
~string() dtor
~string() dtor

However, given the following g++ compilation versions:

g++ -v -o p4 p4.cc
gcc version 1.36.0- (based on GCC 1.36)
 /usr/local/gnu/1.36/lib/gcc-cpp -+ -v -I/usr/local/gnu/1.36/lib/g++-include -undef -D__GNUC__ -D__GNUG__ -D__cplusplus -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ p4.cc /usr/tmp/cca02667.cpp
GNU CPP version 1.36
 /usr/local/gnu/1.36/lib/gcc-cc1plus /usr/tmp/cca02667.cpp -quiet -dumpbase p4.cc -version -o /usr/tmp/cca02667.s
GNU C++ version 1.36.0- (based on GCC 1.36) (sparc) compiled by GNU C version 1.36.
default target switches: -mfpu -mepilogue
 as -o p4.o /usr/tmp/cca02667.s
 /usr/local/gnu/1.36/lib/gcc-ld -o p4 -e start -dc -dp /lib/crt0.o -L/usr/local/gnu/1.36/lib p4.o -lg++ /usr/local/gnu/1.36/lib/gcc-gnulib -lc

I get the following output:

string(char*) ctor
string(char*) ctor
string::operator char*()
string(char*) ctor
~string() dtor

indicating implicit conversion temporaries aren't being destroyed.
No, I don't defend this coding style...

-Page