"gcc -Wall -O " does not like my fstream arrays. Why?

Here is my code:

#include <fstream>

void subr() {
  fstream *fout = new fstream[1];
  fout[0].open("Afile", ios::out | ios::binary);
  fout[0].close();
}


Here are the error messages that I get when
I compile it with:  "gcc -Wall -O4 -c cReads.cc"

cReads.cc: In function `void subr()':
cReads.cc:5: warning: variable `class fstream * this' might be clobbered by `longjmp' or `vfork'
/util/include/g++/fstream.h:83: warning: variable `class fstreambase * this' might be clobbered by `longjmp' or `vfork'

Interestingly, if I compile without -O4 I do not
get an errpor message.  (I do get error messages
with -O though.)

I am curious about why I get the error messages
but I am even more interested in learning a clean
way to handle fstream arrays.  (In my real code,
fout is an array with many elements, not just 1).

Thanks,
  Ken
klopterAsked:
Who is Participating?

[Webinar] Streamline your web hosting managementRegister Today

x
 
KangaRooConnect With a Mentor Commented:
Both with 2.8.1, when using vector<fstream> a whole list of errors. With C array's and the combination -Wall -O4 the longjmp warning.

I just tried it with gcc 2.95 and both the vector and the array version compile.
0
 
klopterAuthor Commented:
I am using gcc version 2.8.1 on a Compaq/DEC
alpha.

When I compiled the same code on gcc version 2.7.2.3 on redhat linux I get no warnings.

Ken
0
 
nietodCommented:
longjump and vfork are elements of C that have a bad affect on C++ and should never be used in a C++ program (or, probably, a C program for that matter).   My guess is that the compiler thinks that this program is a C, not C++ program and is warning you that using these C++ things (new and fstream) in a C program is risky.  Is there a compiler option to tell the compiler whethor not the source is C or C++?  Sometimes this determination is made by the file extesion.  Is ".cc" the right extension to use?  You might try ".cpp"
0
Never miss a deadline with monday.com

The revolutionary project management tool is here!   Plan visually with a single glance and make sure your projects get done.

 
KangaRooCommented:
cpp or .cc extension should tell the compiler its dealing with C++
0
 
nietodCommented:
Kangaroo, you use gcc don't you?  Do you get this error?

Another thought, what if the compiler detected the use of longjump or vfork?  Do you use them?  Do you include files or link to files that might use them?   If you create a small stub program with just main() and the code above, do you get the error?
0
 
KangaRooCommented:
Yep (gcc 2.8.1). Its the combination -Wall and -Ox that introduces these warnings.
fstream.h Line 83:
    fstream() : fstreambase() { }

fstreambase::fstreambase() is only declared.

The warning does not occur whe using vector<fstream> rather then a simple array.
0
 
nietodCommented:
>> Its the combination -Wall and -Ox that
>> introduces these warnings
Any reasonable reason why?  (I don't know the meaning of those options).

>> The warning does not occur whe using
>> vector<fstream> rather then
>> a simple array.
However, from another question asked by klopter, that seemed to produce some weird warnings about removing const.  Are you finding that?
0
 
KangaRooCommented:
-Wall
  All warnings enabled
-O1 .. -O4
  various levels of optimizations

Using vector<fstream> doesn't produce a single warning or error.
Do you have a Q id on klopter's Q (I remember it only vaguely)?
0
 
nietodCommented:
>> -Wall
>>   All warnings enabled
Oh.  I was thinking like "wall" not "W all", the O  I had guessed at.  
klopter, often displaying all warnings is a mistake.  The compiler often warns about things that it think might be errors but actually are not.

>> (I remember it only vaguely)?
Actually, I don't think you were "there"  It was from yesterday.

http://www.experts-exchange.com/jsp/qShow.jsp?ta=cplusprog&qid=10260314 
0
 
KangaRooCommented:
Hi klopter I see you do some LaTeX to? If you also think there should be a TeX and LaTeX topic area, let the EE staf know on Q at this URL:
http://www.experts-exchange.com/EQ.10255484-2329856
      - or -
http://www.experts-exchange.com/Q.10255484-2329856 (non-cookie login)
0
 
KangaRooCommented:
Mh, I see. Then it was another Q.
0
 
klopterAuthor Commented:
I have now tried both of my codes on close to a dozen different flavors of gcc compilers.  I have found flavors that don't accept <fstream> but do accept
<fstream.h>  I have found flavors that reject ios::binary.  And, I have found two gcc's with identical version numbers that act differently.

All but one of the gcc versions accepts fstream
arrays, but none of them accept my fstream vector
code.  Unfortunately the one that does not accept
the fstream vector code is my main target for this
code.

I have found that I can get eliminate the warnings that I am getting by adding -Wno-unitialized to
the command line, so that will be my solution for now.  I hate to turn off compiler warnings though.
I believe that -Wno-unitialized is the only way
to get rid of this warning, as -Wuninitialized all
by itself is enough to generate the warning.

I am still hoping that my fstream vector code is screwd up somehow, so here it is.  I hope that
someone will try to compile it:

#ifdef NAMESPACE
#include <fstream>
#include <vector>
using namespace std;
#else
#include <fstream.h>
#include <vector.h>
#endif
void subr() {

  vector<fstream> fout(1);
  fout[0].open("Afile", ios::out | ios::binary);
}

If it is easier for you , you can download it at:

http://waldo.wi.mit.edu/~kstanley/codes/file_descriptor_vector.cc


Here is my fstream array code:

#ifdef NAMESPACE
#include <fstream>
#else
#include <fstream.h>
#endif

ofstream fout[64];

void subr() {

  fout[0].open("Afile", ios::out | ios::binary);
  fout[0].close();
}

And, you canpick this up at:

http://waldo.wi.mit.edu/~kstanley/codes/file_descriptor_array.cc

Thanks for all of your helpful advice.

Ken
0
 
nietodCommented:
>> flavors that don't accept <fstream> but do
>> accept <fstream.h>
Those are old.  <fstream> is the standard.  <fstream .h> is older.

>> I have found two gcc's with identical version
>> numbers that act differently.
Probably the same version of the compiler, but with different versiosn of the standard library include files.

Do yourself a favour.  download the latest version of gcc.  In the past few years, while the standard was being developed, there were lots of changes and that lead to this sort of thing.  But now there's a standard and gcc's recent version are extremely close to the standard.
0
 
KangaRooCommented:
I have the same problem with gcc 2.8.1. Will try with newer version asap.
It appears that an fstream base class has the copy constructor private :( Can probably only work around with inserting...
0
 
nietodCommented:
>> It appears that an fstream base class has
>> the copy constructor private
Is it legal to copy a stream????  I need to look into that.  If not, a vector is not going to be allowed.
0
 
klopterAuthor Commented:
OK I have download the latest version of gcc.  In general I resist using the latest version of compilers because I want my code to be portable and I find that code that it is usually easier to port from
older versions to newer versions than the other way around.  

But, in this case my problem isn't with the compilation, per se, but rather with the warnings.
Besides it can't hurt me to have both versions around.

To KangaRoo - Which problem do you have?
The problem with fstream arrays or with fstream vectors?

Thanks,
   Ken
0
 
nietodCommented:
>> I find that code that it is usually easier to port from
>> older versions to newer versions than the other
>> way around.
That used to be be true, because the newer versions were adding features to C++ that weren't in the older versions.  Now we're past that.  These days most compilers support all the C++ features (exceptions, templates, namespaces, etc) but they differ in how well they follow the standard in the millions of picky little details.  So it is best to stay up-to-date because the compilers are all homing on one one standard, so as compilers advance they become more compatible.

At the moment, I do not see anything in the standard that specifies that a stream is to have a private copy constructor.  But, I need to search more.
0
 
klopterAuthor Commented:
Just one last question:

Does the vector code need a destructor?

If not why not?

Ken
0
 
klopterAuthor Commented:
Thanks for all the help from all of you (MikeBlas,
KangaRoo and nietod).  Having given the points
on the other Q to  nietod I give these points to
KangaRoo.

I will continue to  use the array version becuase it
seems more portable but I will start using vectors
for other  less exotic arrays.

To MikeBlas:
    I agree about the importance of assert's and code reviews.  I use assert's a lot and have tried to initiate code reviews in the past.    I am not new to C programming only to C++  programming.

Thanks again,
  Ken
0
 
nietodCommented:
What do you mean by that?

A vector will destroy the objects it stores.  That is, if the objects in a vector have a destructor, those destructors will be called when appopriate.  For example, if the vector shrinks in size, the destructors for the objects at the end wil be called, also when the vecotr is destroyed the destructors for the objects stored will be called.  You will also find that the destructors are called at other times too, though, like if the vector expands and runs out of memory in its currently allocated block, it will allocate a new block, copy the objects from the old one to the new one, and then destroy the old one, calling the destructors for the objects in it.)

I don't see any restriction in the standard that requires that the copy constructor in a stream be private, so you should be able to create vector's of stream objects.
0
 
KangaRooCommented:
Thanx!

vector<T> requires its parameter (T) to have at least a destructor, a copy-constructor and, usually, an empty constructor. vector allocates memory to hold objects, initializes them and must also be able to destroy them and free the allocated memory.
0
 
klopterAuthor Commented:
Sorry that I am having trouble speaking C++

When I asked does the vector code need a
destructor what I meant was does the code that
I wrote which I will copy down here have a memory
leak or some other inadequacy.

In other words,  "vector<fstream> fout(1);" must allocate some memory somewhere.  How is this memory freed?

Ken
0
 
nietodCommented:
The memory for a vector is allocated and freed using an alocatator object, which is a paramamter specified to the vector<> template.  Since you didn't specify the parameter (I don't think anyone EVER has.) it defaults to an object that ends up just calling new[] and delete[].

vector as well as all the STL classes function "properly".  They will not produce memory leaks or other problems so long as they are instanciated with "propperly working" classes.  i.e if your constructor, destructor, copy constructor and operator = all work right, any STL class if this class will work right too.
0
 
KangaRooCommented:
fout is an automatic. It gets constructed and destructed automatically, when it 'goes out of scope':

void f()
{
   int* intArray = new int[235]; // dynamically allocated, requires delete
   vector<int> vec(12); // automatic
   // ....
   delete []intArray; // dynamic, new and delete shold be paired
} // vec goes out of scope and is destructed automatically.
0
 
klopterAuthor Commented:
Sorry that I am having trouble speaking C++

When I asked does the vector code need a
destructor what I meant was does the code that
I wrote which I will copy down here have a memory
leak or some other inadequacy.

In other words,  "vector<fstream> fout(1);" must allocate some memory somewhere.  How is this memory freed?

Ken
0
 
klopterAuthor Commented:
Thanks.  

That all makes sense.

Ken
0
All Courses

From novice to tech pro — start learning today.