From: khan AT xraylith DOT wisc DOT edu (Mumit Khan) Newsgroups: comp.os.msdos.djgpp Subject: Re: -frepo flag, is it supported? Date: 18 Oct 1998 18:17:03 GMT Organization: Center for X-ray Lithography, UW-Madison Lines: 45 Message-ID: <70dbav$i4i$1@news.doit.wisc.edu> References: NNTP-Posting-Host: modi.xraylith.wisc.edu To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com In article , Eli Zaretskii wrote: > >On 18 Oct 1998, Mumit Khan wrote: > >> - use a temporary file. Write a popen like replacement that redirects >> both stdout and stderr. I believe the djgpp's popen already uses temp >> files, so it's already there in source form to reuse. > >Since DJGPP's `popen' already exists, the simplest change is just to use >it instead of the usual Unix fork/exec paradigm. Please note that the "... both stdout and stderr ..." statement above. All implementations of popen I know of redirect only stdout, so you can't just use popen. If djgpp's popen redirects both to the same descriptor, then that's a non-standard behaviour that I'm not aware of. (I'm not a djgpp user) >> - dup/save the parent's stdout/err, spawn the child with the new >> descriptors for stdout/err, restore parent's stdout/err and read >> from the child's stdout/err. > >This is exactly what `popen' does, so why reinvent the wheel? See above. >Of course, the real question is does DJGPP at all need -frepo? If this is the real question, then perhaps you're not a C++ developer, and the issue is moot. Implicit instantiation is impractical in real life due to code bloat; Explicit instantiation becomes too hard to maintain and get it right portably (eg., different optimization level, and different versions of runtime library, may produce different sets of instances of STL templates); the only usable choice is some form of automatic instantiation in anything other than toy C++ code (or C code written in C++ or C++ code written without any serious templates). "-frepo" may be a hack at heart, but it's better than anything currently available for GNU C++. Regards, Mumit