quote:Original post by Ready4Dis
Well, turns out, that since it was crashing, my data wasn''t ever getting written to my file. Now I close it after each write, and open it for append.

What''s wrong with using an unbuffered stream?

quote:
As for the topic argument, I like to close things myself, even if they have destructors. I normally use C, and that is was I am accustomed to.

"I normally use C" is a sad example of the dogma I mentioned earlier. What''s C got to do with the right way to do things in C++? Remember, "a bad programmer can write Fortran in any language".

quote:
It can NEVER hurt to close it yourself

This is an absolutism that requires you to have thought about all possibilities. I don''t believe you have. For starters, you might be breaking the symmetry of your design if you opened the file in the ctor. Don''t think that''s a problem? I do - symmetry makes a design easier to understand, since it means there is less to remember. This becomes more relevant the larger your codebase. Try working on a large project which shuns symmetry of concept - it makes a big difference. RAII is a great way of achieving symmetry in C++.

I wasn''t going to say anything more, but you''ve raised some interesting points...

quote:Original post by Anonymous Poster
A thought that I have on the topic which I find interesting (but not terribly surprising) is that nobody has mentioned the principles of software engineering at all anywhere in the thread

I did make a vague reference to symmetry earlier on, but I think it got lost in the noise (or I didn''t emphasise it very much). I''ve said some more about it since.

quote:
to use approaches like not closing things that are open complicate the debugging and maintenance of the project for future coders.

I''m gonna have to say it again: it''s not a case of not closing things, it''s a case of understanding that the dtor deals with closing the file, and arranging your surrounding concepts to take advantage of that. If implicitly closing a file makes a system harder to understand, then I suspect that''s as a symptom of the enclosing scope being badly organised. I think you''re taking the rule "always be explicit" and failing to offset it against other ideas.

quote:
There are several principles that apply here which come to mind - localization, readability, maintainability, and perhaps uniformity seem very relavent.

Yup, but apparently not self-evident as I have exactly the opposite view to you whilst considering these same concepts.

quote:
Can the principles be applied and still follow the technique whereas some contributors would rely on the compiler to close files (in this instance) implicitly?

I don''t think I understand this sentence.

quote:
Perhaps, but then we begin to assume a lot about the skills and knowledge of the coders that we work with and any future coders that work on the project. That''s a fairly hefty gamble. It can be effectively disregarded by a blanket statement in which one holds all of the programmers in an organization to a minimal level of mastery of their environment, but that''s not terribly realistic.

This is a good point, but I can''t resist poking it a bit. Firstly, if you''re talking about incompetence, that can work both ways. When writing code, you have an intended audience. Or rather, two intended audiences: other people and the computer. Other people means competent programmers who are familiar with the language. If the actual audience ends up being incompetent programmers then that is a problem of the organisation''s hiring policy, not a problem with the way you''ve written the code. You cannot write s/w for incompetent programmers - you simply can''t second guess what they will be able to understand. The last point on this is to remember what we are talking about: we''re discussing closing a filestream object. It''s not an esoteric subject.

quote:
Nor is it realistic or fair to dismiss the concern by simply stating that one should have intimate knowledge of the environment that they''re working in - people have to develop the experience from somewhere, and not everyone will have that express knowledge even with years of experience if they''ve never worked with a specifically related problem.

They can RTFM. Remember, this is only an ofstream. Surely you''re not saying only highly competent programmers know how to read something like Josuttis, are you?

quote:
I suspect I''m probably severely biased in that I''m a programming teacher in a school where software engineering is heavily emphasized. Now after a few years teaching here it''s really become part of my techniques and habits.

Software engineering is a fast-moving target. Many designs that would have been good 10 years ago are shunned today. Witness pre-STL container frameworks.

quote:
the overhead would be negligable if any, but the understandability of what was written would increase significantly.

That depends. If you break symmetry, you hamper human understanding. In addition, an explicit close() also introduces coupling into your design. OK, so it''s only export coupling, but it''s still avoidable coupling, no?

quote:
Perhaps if explicitly closing files was a technique that bothers some who feel it would be wasted time, would it be just as evil to perhaps place a comment at the end of the message processing stating that the file is not explicitly closed due to the fact that it is closed by the destructor at the loss of scope and call it a compromise?

That would be worse. I''d even favour explicit closing over that suggestion. You would both be adding a needless comment, thus introducing another maintenance point, whilst explicitly stating you are programming for an incompetent audience. Since you are interested in s/w engineering, you should realise how much damage an incompetent programmer can cause.

Anecdotal evidence leads me to believe the s/w industry would be better off with *less* people, by getting rid of the incompetents and thus improving the average ability. Certainly, I''ve been in jobs where the majority of my time has been spent dealing with the accidental complexity created by idiots. Time which would have been better spent responding to business needs, thus making the organisation more competitive.

I use msdev compiler, but the code I write has to compile on othr platforms, (PS2, NGC, Xbox ). And as my collegues would agree its imperetive[sic?] to tidy up as you go along explicitly. Mainly so when someone else looks at your code it is clear what you meant. This could be resolved in the above situation by putting the following comment:-

// file is closed implicitly when var goes out of scope
ostream MyFileHandle;


Although personally I prefer to call .close().

quote:Original post by Mark Duffill
I use msdev compiler, but the code I write has to compile on othr platforms, (PS2, NGC, Xbox ).

What''s that got to do with it? ofstream is part of the C++ Standard Library, and is specified as closing in the dtor. It''s got nothing to do with what your compiler vendor decided (unless they decided to flagrantly depart from the Standard, in which case you have a different problem).

quote:
And as my collegues would agree its imperetive[sic?] to tidy up as you go along explicitly. Mainly so when someone else looks at your code it is clear what you meant. This could be resolved in the above situation by putting the following comment:-

// file is closed implicitly when var goes out of scope
ostream MyFileHandle;

Why would you put a comment stating that? Do you also do this:

std::ofstream out("log.txt"); // this implicitly opens the file in write-replace mode 

or this...

std::string s; // this creates an empty strings.c_str(); // this returns a pointer to a zero-terminated array of characters 

It''s all information that you can get from any reasonable C++ reference. The point is you don''t write comments to explain how the language works - you expect the programmer to have some level of competence, else they shouldn''t be paid to work unsupervised on code.

There was a point brought up multiple times here that symettry should be preserved, if you open with .open(), then you should close with .close(). But you''ve failed to mention that I open with the constructor, and will thus close with the destructor.

Note also that I don''t believe in writing "paranoid" code, where functions that couldn''t possibly fail are checked for failure, etc.. such coding practices make code longer, harder to understand, and longer to produce.