Using fstream pointers

**sean_cantab** · 10-31-2016

Thanks to both for your feedback, for 'cleaner' solutions to 1 and 2 I'd:

Code:

//1;
bool is_special(std::string result) {
   return result == "special";
}
//2.
cin>>size;
Coord coords[size];
//... as before;

I've just drunk the smart-pointer Kool Aid and therefore wherever I saw a raw pointer my inclination was indeed to get rid of it and replace it with a smart one. Such a sledgehammer approach is probably (definitely?) wrong and when I read Elysia's comments in #13 I realised that there are severe limitations to this approach.

**Xupicor** · 10-31-2016

#1 - naming the parameter "result" is kind of confusing. :P But to the meat of things - the copy might be optimized out, or it might not, it'd be even better if you passed the string by const reference.
#2 - are you using VLA in C++? VLAs are not actually part of C++ even if they work for you as an extension (you're not compiling with -pedantic). Why not a... you know, std::array, or std::vector that you resize manually so that it doesn't waste time with reallocations.

#4 - sometimes you'll work with legacy libraries - they will want a pointer to this or a pointer to that... In that case the memory is managed by the smart pointer, so you don't have to worry about that. You know it'll be 'live' during the time of that call, so you can safely just throw it a raw pointer. You'd have to do get to it anyway, since you can't change the library interface.
More even - let's say you use a shared_ptr there instead of unique_ptr, and return a shared_ptr by copy. Your large frame goes out scope, but before that happens you took a shared_ptr to its data and stored it somewhere. Your frame is dead, but part of its internal data is alive. Is that good? Should you even let that happen?

Thread: Using fstream pointers

Thread Tools

Search Thread

Display

Similar Threads

How would this look if I used fstream?

fstream not .h

About "fstream" in <fstream.h> and <fstream>

fstream

fstream

Tags for this Thread