CStringList on heap
-
Is there any point to create a CStringList class member on heap (with new) if this member has a lot of elements ? Or is enough to declare it on stack ?
-
Is there any point to create a CStringList class member on heap (with new) if this member has a lot of elements ? Or is enough to declare it on stack ?
no point, really. Anyway, stop using CStringList and use a std::vector instead.
I'd rather be phishing!
-
// header
protected:
CStringList m_List1;
CStringList m_List2;
CStringList m_List3;
CStringList m_List4;COutputWnd::COutputWnd() noexcept
{
m_List1.AddTail(_T("Item 1"));
m_List1.AddTail(_T("Item 1"));
m_List1.AddTail(_T("Item 1"));
m_List1.AddTail(_T("Item 1"));
m_List1.AddTail(_T("Item 1"));
m_List1.AddTail(_T("Item 1"));m\_List2.AddTail(\_T("Item 2")); m\_List2.AddTail(\_T("Item 2")); m\_List2.AddTail(\_T("Item 2")); m\_List2.AddTail(\_T("Item 3")); m\_List2.AddTail(\_T("Item 55")); m\_List2.AddTail(\_T("Item 44"));....
}or should I do a CSringList* m_pList1, and in c-tor I create m_pList1 = new CStringList ? That was the question.
-
no point, really. Anyway, stop using CStringList and use a std::vector instead.
I'd rather be phishing!
-
Thank you. I would let this CStringList as it is now. I still have a question: Why should I use std::vector instead of CStringList ? Is there a plus ? Please note that my app is VC++/MFC, and CStringList is part of MFC.
-
Thank you. I would let this CStringList as it is now. I still have a question: Why should I use std::vector instead of CStringList ? Is there a plus ? Please note that my app is VC++/MFC, and CStringList is part of MFC.
In my experience, if there is a class for your purpose to be found in STL, then it's much better to use that than a corresponding MFC class. The only exception is when you need the MFC structure to interface with a function from a third party library. (e. g. to pass it as a function argument) The 'plus' is that - you could port the code to any platform that does not have or use MFC - you can use other third party libraries that don't use MFC (e. g. most third party libraries using strings in their API will use std::string, not CString) - it's easy to find plenty of documentation and tutorials on the web, and they are all accurate, because existing behaviour of STL types never changes - the types and functions will work very efficiently and not carry around needless ballast related to Windows stuff - your global namespace doesn't get cluttered with symbols and macros - you don't suffer from header dependencies, and don't need to care about order of include statements The 'minus' is that - for some types the STL equivalent provides less utility functions (e. g. std::string vs. CString) - if you're already using MFC types elsewhere and don't intend to change all of them, you may need to convert data between MFC- and non-MFC types. As for using std::vector instead of std::list, the reason is that as long as you don't delete items in the mid or at the start of the vector, it is much faster than a list.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
// header
protected:
CStringList m_List1;
CStringList m_List2;
CStringList m_List3;
CStringList m_List4;COutputWnd::COutputWnd() noexcept
{
m_List1.AddTail(_T("Item 1"));
m_List1.AddTail(_T("Item 1"));
m_List1.AddTail(_T("Item 1"));
m_List1.AddTail(_T("Item 1"));
m_List1.AddTail(_T("Item 1"));
m_List1.AddTail(_T("Item 1"));m\_List2.AddTail(\_T("Item 2")); m\_List2.AddTail(\_T("Item 2")); m\_List2.AddTail(\_T("Item 2")); m\_List2.AddTail(\_T("Item 3")); m\_List2.AddTail(\_T("Item 55")); m\_List2.AddTail(\_T("Item 44"));....
}or should I do a CSringList* m_pList1, and in c-tor I create m_pList1 = new CStringList ? That was the question.
-
Thank you. I would let this CStringList as it is now. I still have a question: Why should I use std::vector instead of CStringList ? Is there a plus ? Please note that my app is VC++/MFC, and CStringList is part of MFC.
-
Is there any point to create a CStringList class member on heap (with new) if this member has a lot of elements ? Or is enough to declare it on stack ?
_Flaviu wrote:
... if this member has a lot of elements
Just to make a point: the elements of a container do not affect how the container itself looks like, or how it should be allocated. This is true for all STL containers, and also for CStringList. Containers are typically designed like this: one central data structure to store the basic info about the container, and maybe it's state, and some kind of reference (or two) to the data structure(s) containing the elements. The container will take care about allocating memory for the elements on the heap. But the central structure will never need to be reallocated, nor is it very large. Therefore it is no problem at all to allocate a container on the stack. That said, if you pass a container to a function, you should normally pass it by reference. If you don't, the container will be copied as a whole, including all the elements!
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
_Flaviu wrote:
... if this member has a lot of elements
Just to make a point: the elements of a container do not affect how the container itself looks like, or how it should be allocated. This is true for all STL containers, and also for CStringList. Containers are typically designed like this: one central data structure to store the basic info about the container, and maybe it's state, and some kind of reference (or two) to the data structure(s) containing the elements. The container will take care about allocating memory for the elements on the heap. But the central structure will never need to be reallocated, nor is it very large. Therefore it is no problem at all to allocate a container on the stack. That said, if you pass a container to a function, you should normally pass it by reference. If you don't, the container will be copied as a whole, including all the elements!
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
In my experience, if there is a class for your purpose to be found in STL, then it's much better to use that than a corresponding MFC class. The only exception is when you need the MFC structure to interface with a function from a third party library. (e. g. to pass it as a function argument) The 'plus' is that - you could port the code to any platform that does not have or use MFC - you can use other third party libraries that don't use MFC (e. g. most third party libraries using strings in their API will use std::string, not CString) - it's easy to find plenty of documentation and tutorials on the web, and they are all accurate, because existing behaviour of STL types never changes - the types and functions will work very efficiently and not carry around needless ballast related to Windows stuff - your global namespace doesn't get cluttered with symbols and macros - you don't suffer from header dependencies, and don't need to care about order of include statements The 'minus' is that - for some types the STL equivalent provides less utility functions (e. g. std::string vs. CString) - if you're already using MFC types elsewhere and don't intend to change all of them, you may need to convert data between MFC- and non-MFC types. As for using std::vector instead of std::list, the reason is that as long as you don't delete items in the mid or at the start of the vector, it is much faster than a list.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
Stefan_Lang wrote:
- you could port the code to any platform that does not have or use MFC
In my experience in non-trivial (legacy) applications that possibility does not exist unless one refactors the entire code base. That of course precludes those cases where the application, from its inception, was written to support multiple platforms.
-
Stefan_Lang wrote:
- you could port the code to any platform that does not have or use MFC
In my experience in non-trivial (legacy) applications that possibility does not exist unless one refactors the entire code base. That of course precludes those cases where the application, from its inception, was written to support multiple platforms.
Nowadays it's not nearly as bad as it used to be. The biggest culprit was and still is the UI, and in fact any graphics or sound functionality, simply because there are no C++ standard libraries for that. However, there are OS independend libraries around for that purpose. Everything that is in the C++ standard libraries, including STL and BOOST, should work out of the box on any OS without changing the code, unless the compiler you're using is not adhering to the standard (in which case you should consult your compilers compatibility documentation).
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
