Re: How do we use an ifstream vector?
* James Kanze:
On Feb 2, 1:39 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* James Kanze:
On Feb 2, 12:30 am, "Alf P. Steinbach" <al...@start.no> wrote:
* maria:
[...]
typedef boost::shared_ptr< std::ifstream > IfStreamPtr;
std::vector<IfStreamPtr> in;
For once:-). Agreed. This is one place where shared_ptr is
just the ticket. (Of course, the next version of the standard
will support move semantics, and will allow a vector of
ifstream. But I wouldn't count on it any time soon.)
State which other uses you think have been inappropriate.
Most. There seems to be a mode for using shared_ptr everywhere.
In practice, it's only appropriate in particular situations.
Well. From the tone & formulations in the rest of the article I thought
the above was an attempt at implying, without saying so, that there had
been instances of me using shared_ptr really inappropriately, which you
had caught ("for once" agreed). Evidently that was not what you meant;
instead, it seems you meant that shared_ptr is overused in general.
But I don't think that's necessarily a bad thing.
For it is better with safe code that is perhaps a little less efficient
and a little more wordy than necessary, than unsafe use of raw pointers.
And also, teaching programmers to use a large ensemble of different
dedicated smart pointers correctly, is much more difficult than simply
promoting use of shared_ptr. As I recall, being a kind of simple potato
(can be used for just about anything and providing one common type for
shuffling data around) was a design goal of shared_ptr, and one reason
why extremely customizable policy based pointer was not adopted.
Or, from a practical point of view, to avoid having to deal
with all that, but also then coding without a safety net,
just use a raw array of ifstream, default-initialized, and
then open() each one.
I'm not sure where the problem with that is, if the array is a
local object. With g++, at least, unless you're compiling with
the options I mention above, you don't have any safety net with
vector, either, and with Sun CC (with either the Rogue Wave
version of the library or the STL port), there aren't even any
options to provide the safety net.
There is a safety net.
Where?
If you don't want that safety net, then use the C standard
library's functionality instead.
It's hard to define an array of a type which has a user defined
constructor in C.
It's even more convenient for this, not to mention, usually
more efficient.
Sorry, I don't understand. How is C more convenient for an
array of std::ifstream?
"C standard library" means you'd make that an array of FILE*.
A std::vector of smart pointers provides various safety nets. In
particular, using push_back (as the example code did) ensures that the
capacity is large enough for the number of items you put in. And it
provides the possibility of using checking at() instead of []. And it's
easier to pass safely as argument to functions. And so on. Of those
mentioned here, only using at() was not exemplified by the code.
That is not meant as an argument in favor of vector for this particular
problem, however, just clearing up what the safety net consists of,
since you're asking.
[...]
This code does some ungood things such as using a magic number
(namely 5) and using ifstream pointers rather than abstracting
up to istream. I couldn't recall whether istream has virtual
destructor or not.
Are you kidding? All classes in the standard which have virtual
functions have a virtual destructor. (In this case, the base
class ios_base has a virtual destructor.)
Nope, I'm not kidding, and I'm not assuming anything iostream
is reasonable.
More FUD. Just because you don't want to bother to learn
something new.
It would be re-memorizing some details of something old, not learning
something new.
You really should stop spreading FUD about iostream. If you
don't like them, don't use them, but they happen to be the best
alternative by far that we have, and used correctly, the
actually work very well.
Write me that old copy-standard-input-to-output-exactly
program, portably for the platforms supporting that (Windows
and Unix suffices).
Formally, of course, it can't be done, either in C or in C++.
QED.
Practically, open both files in binary mode, and:
out << in.rdbuf() ;
does the trick in C++.
I fail to see the problem. Just because you've decided that you
want to be intentionally dense is no reason.
Problem: "formally, of course, it can't be done".
This demonstrates that instead of -- as you maintain --
working well, there are trivial and very reasonable and very
practically useful problems for which they don't work at all.
IO streams, like the C FILE*, are designed around a particular
abstraction. For historical reasons (like FILE*), they support
other functionality, but less well. If you need a tool
implementing that abstraction, iostream is several orders of
magnitude better than FILE*. If you need a tool implementing
something else, then iostream may not be the answer. No tool
can be perfect for everything.
True, but misleading.
This particular tool fails to be applicable to simple problems such as
mentioned above.
It's perhaps worse for the problems where they sort of work,
e.g. giving a false sense of security, being maddeningly
baroch and archaic, requiring overly verbose client code,
often being grossly inefficient, etc. ad nauseam, including
having two-phase initialization both externally and
internally, having hidden modes and failure state, and
exhibiting Undefined Behavior at the slightest provocation,
when safety was the problem they were meant to address.
Are you being intentionally dense, or just stupid. The above is
just name calling, with no justification in fact, as you well
know.
Mirror, James.
Also, language. :-)
But in spite of that, I'll take you seriously, and provide details
refuting your stance:
* False sense of security: fact, yields illusion of type safe operation,
yet with Undefined Behavior, being defined in terms of fscanf.
* Maddeningly baroch and archaic: well, that's subjective, but just look
at code presented recently in this group. It seems to me that most C++
programmers (but not you, you seem to be expert in iostreams) strive
just to get the durned things to /do/ what's needed, except for the most
trivial. The complexity of the resulting code is staggering, and
provides a market for whole fat books detailing how to make them do
simple things.
* Requiring overly verbose client code: "overly" is subjective, but all
the << and >> stuff is bad enough, with manipulators thrown in. You're
one of very few that disagree with this assessment of verbosity.
* Often being grossly inefficient: it's been some years since last I
measured, but then FILE* outperformed iostreams easily, several times
faster (and API-level outperformed FILE*) with g++ and msvc. Also, the
new-fangled templated iostreams were far behind the old non-templated
ones in terms of efficiency. I'd put it as fact.
* Two-phase initialization externally and internally: fact.
* Hidden modes and failure state: fact.
* Undefined Behavior: just try inputting e.g. a hex number, fact.
* Safety as design goal: hm, I'd have a hard time proving that as a
fact, but do you really think it's not a fact, that safety /was not/ a
design goal? That the notion that safety was a design goal has "no
justification in fact", huh? :-)
In short, the so-called /abstraction cost/ seems to be high
for this problem, but might be alleviated by using more
suitable library classes.
More FUD. The only abstraction cost is the extra
allocations of std::vector. Probably not even measurable,
compared to the time used to read a file.
Simply compare (1) the code size, (2) the complexity of the
code, and, although it doesn't matter in practice here, (3)
the (in-) efficiency (which contrary to what you state also
include dynamic allocations of ifstreams and dynamic
allocations inherent in using boost::shared_ptr).
Abstraction cost is not only ineffiency.
The only one really relevant is the complexity at the user
level. It is slightly more complex to have to explicitely
allocate (using a new expression) each of the ifstream, rather
than let the compiler handle it automatically, e.g.:
std::ifstream inputs[ 10 ] ;
For the rest, I doubt that the differences are measurable.
It mounts up, with such complexity added in for just about anything you
want to do.
This is another example of you being not right (wrt. previous
comments).
I wouldn't talk about being right if I were you. Given the
number of idiocies you spout off about iostream.
Language, James. I gather you're referring to the idiocies listed above
which you dismissed as "no justification in fact", such as iostreams
being designed for safety. Well.
The raw array and non-exception-based version:
#define ARRAY_SIZE( a ) (sizeof(a)/sizeof(*a))
bool foo()
{
using namespace std;
static char const* const inFileNames[] = { "a", "b", ... };
ifstream inFiles[ARRAY_SIZE(inFileNames)];
assert( ARRAY_SIZE(inFileNames) >= 5 );
for( int i = 0; i < 5; ++i )
{
if( !inFiles[i].open( inFileNames[i] ) )
{
return false;
}
}
// Do things with the files, then:
return true;
}
Still more FUD. The above is perfectly exception safe. The
only problem it has is that it isn't the usual idiom, so the
reader will ask why.
Yes, it's correct that your comment here is more FUD. :-)
Nobody's said it wasn't exception safe.
And what does your words "non-exception-based" version mean?
"non-exception-based" means that this code is based on signaling
ordinary failure via a boolean return value instead of via an exception.
Instead of the earlier example's "throw", this one has "return".
It would be interesting if you could comment on whether this code /can/
throw exceptions other than for allocation failures. I ask because I
don't know and think you're an expert on technical details of iostreams.
But I allow for possibility that these beasts are complex enough that
even you don't know.
And nobody (except you) have claimed it is [exception safe].
What got into you?
Just sick and tired of your incompentent idiocies.
I'm not one keeping scores, but in this thread it's about 13 to 1 for me
on factual questions. I did goof in one sentence about shared_ptr, and
I'd have corrected that if you hadn't. Conversely, on name calling and
derogatory remarks, it's about 7 to 0 to you, or, as of this paragraph,
it's about 7 to 1 :-). How about striving to reverse that trend?
There are things you know well, but iostream isn't one of them.
That is true.
Cheers,
- Alf
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?