C++ makes me cry.
Author
I have finally sat down to do a large scale project in C++.
However, I am starting to wonder how to do anything (read on).
It is becoming painfully apparent that I can't use vectors on actual data; that I will need to use vectors of pointers. This is because I will be using interfaces extensively. Should I use boost's shared_ptr? What other options are there? Surely they don't manage memory all themselves?
Maybe I should use C#...
Okay.
More seriously, do you have a question? Do you have a specific problem? (No, asking about boost::shared_ptr does not meet the criteria, because Google answers those questions.)
More seriously, do you have a question? Do you have a specific problem? (No, asking about boost::shared_ptr does not meet the criteria, because Google answers those questions.)
Quote:Maybe I should use C#...Maybe you should consider what your goals are first, and then choose the most appropriate tool for the course?
Quote:Original post by thedevdan
It is becoming painfully apparent that I can't use vectors on actual data; that I will need to use vectors of pointers. This is because I will be using interfaces extensively. Should I use boost's shared_ptr? What other options are there? Surely they don't manage memory all themselves?
You don't really need to use boost::shared_ptr if you can organize your memory allocation/deallocation. I allocate/deallocate objects in one place, and pass constant pointers around (to prevent unintended deallocation).
Well, you can have objects which are non-virtual interfaces, with functions which forward onto a member object which has a virtual implementation.
The Envelope Letter Idiom describes this.
You'd probably want to use a smart pointer to hold the InterfaceImpl pointer.
edit: The overall point being that you hold containers of Interface objects, not pointers to Interface objects:
The Envelope Letter Idiom describes this.
class InterfaceImpl;class Interface {public: Interface(InterfaceImpl*); void SomeFunction();private: InterfaceImpl* m_pImpl;};//this is what gets derived from and overriddenclass InterfaceImpl {public: virtual void DoSomeFunction();};void Interface::SomeFunction() { m_pImpl->DoSomeFunction();}You'd probably want to use a smart pointer to hold the InterfaceImpl pointer.
edit: The overall point being that you hold containers of Interface objects, not pointers to Interface objects:
typedef std::vector<Interface> Interfaces;Interfaces i;i.push_back(Interface(new MyInterfaceImpl));i.push_back(Interface(new YourInterfaceImpl));i.push_back(Interface(new AnotherInterfaceImpl));Quote:Original post by alnite
I allocate/deallocate objects in one place, and pass constant pointers around (to prevent unintended deallocation).
It's okay to delete a constant pointer.
Quote:Original post by abnormal
just use c# and your pain will stop, as simple as that!
C# is not a panacea for poor software engineering.
Quote:Original post by antareusQuote:Original post by abnormal
just use c# and your pain will stop, as simple as that!
C# is not a panacea for poor software engineering.
it's a crutch, and will help you. Take Antareus's advice. I have experiance in both, and must say that if you really don't need speed, use C#. msdn.com -> visual studio 2005 beta -> visual C# express. :)
Not to derail this thread, but I've never seen anything that really demonsrates the speed benefits of 'organized' vs. 'deorganized' memory allocation. Does anyone know of websites/articles about this?
Quote:Original post by Sagar_IndurkhyaI don't think it's the right thing to call C# a crutch. Is C++ a crutch because it lets you write constructors and destructors that are called automatically, instead of you having to call them on your own? No. C++ lets you think on a higher plane of thought than C because the programmer is free from having to worry about some unimportant details. Similarly, C#, with its garbage collection, allows the programmer to think on an even higher level and thus make better and more innovative code. By the way, tests show that C# is almost as fast (and sometimes even faster) than C++. The only problem really is the overhead of the .Net framework.Quote:Original post by antareusQuote:Original post by abnormal
just use c# and your pain will stop, as simple as that!
C# is not a panacea for poor software engineering.
it's a crutch, and will help you. Take Antareus's advice. I have experiance in both, and must say that if you really don't need speed, use C#. msdn.com -> visual studio 2005 beta -> visual C# express. :)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement