Re: outcommented fdopen code

On Jun 12, Zeev Suraski wrote: > On Sat, 12 Jun 1999, Jim Winstead wrote: > > > On Jun 12, Zeev Suraski wrote: > > > On Sat, 12 Jun 1999, Sascha Schumann wrote: > > > I'm wondering what to do about it myself, since I want to support > > > include_path and URLs in the C++ version as well (currently it doesn't > > > work, since I need to create an istream * pointer, and there's no way to > > > convert a FILE * to an istream *). > > > > Well, you could simply derive your own FILEistream or somesuch. > > It's not very fun, but not incredibly difficult. We had to do > > something similar on the last project I worked on. > > > I wanted to do it. Would it work though? None of the functions in > class istream are virtual. Miraculously, and I'm not really sure how, > istrstream and ifstream don't seem to override any istream functions, just > add a bit to them, which is why sending ifstream and istrstream pointers > to flex works. I can't see how flex would work with my own derived class > that would obviously have to override the various IO functions of istream. > Since the methods aren't virtual, and since the pointer is always of type > istream *, it won't call my methods anyway... Or am I missing something? > > If I can derive a class from ifstream * it's trivial to write a small > wrapper class that will relay all of the methods flex calls to a FILE * > member, but I want to be sure it will be calling these functions, and not > istream's functions. istream derives from something else, which is where the virtual functions you need to override lay. (If I remember right, it's actually another class like streambuf or something that is where most of the implementation lives.) I've got a book around somewhere that covers this. I'll see if I can't dig it up. (Hope I didn't give it to the programmer who actually did the implementation of that stuff on my last project...) Jim