Different Object Model in g++-2.95 and g++-3.3.5?

[holderlin]

Hi, all:

I compiled the following code using g++-2.95:
-
#include 
using namespace std;

class A {
public:
virtual void echo () {};
};

class B: public virtual A {
public:
int b;
virtual void echo () {};
};

int
main()
{
cout << sizeof(A) << endl;
cout << sizeof(B) << endl;

return 0;
}

The result is:
4
12


If I compile it using g++-3.3.5, the result is:
4
8

So I am wondering whether g++-3.3.5 changes its object model.



---
Holderlin Zhang
Department of Applied Math., Nankai University

What's the difference between (*(x)).a and (x)->a

[holderlin]

Hi,

Is there any difference between (*(x)).a and (x)->a, if x is an
expression which generates a struct pointer.
I found the assembly code of these two generated by gcc are the same.
But is the implementation compiler dependent? Or do they just have the
same meaning expressed in different syntax?

Thanks,
Steven

ofdstream.h and segmentation fault

[holderlin]

Hi, all:

I used an ofdstream.h written by others:

->>>>>>>>>>>---<<<<<<<<<<<<
#ifndef _OFDSTREAM_H
#define _OFDSTREAM_H

#include 
#include 
#include 

class ofdstream: public std::ofstream
{
private:
   __gnu_cxx::stdio_filebuf< char > m_buf;
   int m_fd;
public:
   ofdstream( int fd, int bufsize = 4096 );
   int fd() const { return( m_fd ); };
};

inline ofdstream::ofdstream( int fd, int bufsize )
#if __GNUC_PREREQ (3,4)
:   m_buf( fd, std::ios_base::out, bufsize )
#else
:   m_buf( fd, std::ios_base::out, true, bufsize )
#endif
{
   //this->init(&m_buf);
   std::basic_ios< char >::rdbuf( & m_buf );
}

#endif // _OFDSTREAM_H

->>>>>>>>>>>---<<<<<<<<<<<<

And the below is my test a.cpp:

->>>>>>>>>>>---<<<<<<<<<<<<
#include "fdstream.h"
#include 
#include 
#include 
#include 
#include 
using namespace std;
int
main()
{
   int fd = open("a.log", O_WRONLY|O_CREAT, 0600);
   if (fd < 0) {
   cerr << "open error" << endl;
   exit(1);
   }

   ofdstream ofs(fd);
   ofs << "testtest" << flush;
   close(fd);
   return 0;
}
->>>>>>>>>>>---<<<<<<<<<<<<

compile and run it:
# g++ -g -o a a.cpp
# ./a
Segmentation fault (core dumped)
#  g++ -v
Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2/specs
Configured with: ../gcc-3.2/configure --prefix=/usr --enable-shared
--enable-languages=c,c++ --enable-threads=posix --with-slibdir=/lib
--enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 3.2

The below is backtrace of the core dump:

(gdb) bt
#0  0x40167d46 in free () from /lib/libc.so.6
#1  0x40157de7 in fclose@@GLIBC_2.1 () from /lib/libc.so.6
#2  0x40053ca4 in std::__basic_file::close () from
/usr/lib/libstdc++.so.5
#3  0x4005388f in std::__basic_file::~__basic_file () from
/usr/lib/libstdc++.so.5
#4  0x4008b64f in std::basic_filebuf

::~basic_filebuf () from /usr/lib/libstdc++.so.5

#5  0x08049a5a in ~stdio_filebuf (this=0xb9fc) at
/usr/include/c++/3.2/ext/stdio_filebuf.h:115
#6  0x08049778 in ~ofdstream (this=0xb970) at a.cpp:19
#7  0x0804969d in main () at a.cpp:25


But if I compile  a.cpp with g++ 3.4.4, there is no segmentation fault.

I failed to find and fix the bug.
Is this a bug in libstdc++?




---
Holderlin Zhang
Department of Applied Math., Nankai University