Yes, should I try to throw it at the stack?
Problem is the string function will try to allocate from the heap and fail.
Yes, should I try to throw it at the stack?
Problem is the string function will try to allocate from the heap and fail.
Then don't add a string, or provide just a small, static buffer. But really, is it that important?
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
Tried providing small, static buffers, but it just doesn't want to work right when other function try to allocate like MFC's idiotic CMemoryException class (which can't return an error through a function with a CString reference).
But ah... it doesn't really matter that much with memory shortage. Likely the whole program will crash anyway.
Oh, yeah, forgot another assumption my smart pointers make: that when given a raw pointer, they have exclusive access to it. If allocation of the share count fails, they will delete the pointer.
Eh, reminds me that I have a bug in there. Hold on a second.
Ah, there you go.
By the way:
Do you realise that virtual functions carry a speed overhead?Uses virtual functions to determine if to call the time critical functions or not.
Last edited by CornedBee; 11-01-2007 at 10:42 AM.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
BTW, instead of making different smart pointers for single vs arrays... My AutoPtr deletes memory in any way you want by passing in a custom "deletor" functor. You can write a deletor to do delete p; or delete [] p; or free( p ); or anything else you can think of.
Actually you could probably use it as a general purpose RAII object, maybe with some small changes...
Well, as you all have mentioned, vector is enough for arrays AND for buffers so support for arrays is not necessary.
The smart pointers in std::tr1 are probably enough for any other smart pointer needs your class is trying to achieve as well. I thought that wasn't the point.
I found another dangerous behaviour today:
As far as I'm concerned, it shouldn't work at all since we're passing strFiles when we haven't declared it. What's worse is that the compiler will create strFiles and pass it to the function without calling the objects constructor, thus resulting in a crash.Code:pp< vector<CString> > strFiles = Stuff::FindFiles(Stuff::GetWindowText(m_Directory), m_Recursive.GetCheck() == 1, _T("*.*"), NULL, NULL, strFiles, false, NULL, NULL);
Last edited by Elysia; 11-02-2007 at 02:32 PM.
Sometimes you can do bad things in C++. If there's nothing stopping you from doing it with int or string, then I wouldn't worry about it for your class.Code:int main() { int i = i + 0; std::string str = str + "World!"; }
Apparently this compiles without a warning:
My output is 16384 (should be 10 if the constructor was called before print).Code:#include <iostream> class A { public: A(): value(10) {} void print()const {std::cout << value << '\n';} private: int value; }; A foo(const A& a) { a.print(); return A(); } int main() { A a = foo(a); std::cin.get(); }
I guess this might be a problem of the language that it allows it. But then you should just avoid writing code that cannot possibly make sense (using an instance to construct the same instance) and stop worrying about particularly broken use cases when designing classes.
I might be wrong.
Quoted more than 1000 times (I hope).Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
return A();
isn't that the equivalent of returning a local variable?
It's ok, because the function returns by value.
oh ok.