|
I recommend STL because it is extensible, i.e. it goes where C++ goes.
Kuphryn
|
|
|
|
|
Maybe I don't know what that means. I always thought 'extensible' meant you could extend its functionality, not its portability. At present, all of my development work is on Windows machines so the portability is not an issue to me (for the immediate that is). You can certainly extend MFC just as you can STL, so I don't see this as being a viable argument. Granted, I am not a highly paid engineer with degrees mounted on my walls, so please do not take offense to my statement that it doesn't make much sense to claim superior extensibility when this hardly seems the issue.
Thank you,
John
|
|
|
|
|
In any given software design, the developer should always design and implement it such that it is as portible as possible. Yes, you are set on Windows, but how about Win32 console when Microsoft releases something better than MFC? Note you will have to reimplement the software for MFC is not C++ standard tool.
For extending functionalities, STL definitely tops MFC. STL offers many more tools than MFC has to offer. For example, STL offers the std::pair key/value element type for all containers.
Kuphryn
|
|
|
|
|
Yes, you are correct, I should have developed my current project (and others in the past) more modular and less dependant on current technology and more reusable, which is one of the reasons I am investigating STL. As my current work is essentially a wash anyway, I am not concerned about it, but my next project, which replaces this one in the market, will follow these ideals to the best of my ability. The problem is that my work is almost 100% GUI and MFC is the best choice for that right now - unless you know of "better" alternatives.
Thank you for you advice,
John
|
|
|
|
|
MFC is an essential solution for Windows applications especially the GUI components. Other than the GUI component, I recommend other tools beside MFC. Top of the list is STL. Other tools depends on the project such as graphics, network, databases, etc.
Kuphryn
|
|
|
|
|
Once you get familiar with STL containers, I guess you would never use MFC containers again. Atleast, that was the case with me.
First of all, generic algorithms exist. As Tim pointed out, they may not give you the best performance possible - but, how many times do you need that performance - I would say a very negligible fraction.
For example, I had a loop that executed 10000 times a second, and had some container operations on it. Using a custom allocator, I was able to speed up the operations dramatically. This shows the flexibility that STL hands you in improving performance of pre-written code. To give another example, the hash_map in the STL that comes with VC7 is highly configurable - including the hash function, where as CMapStringToPtr does not allow me to customize the hash function.
Another thing that I would like to emphasize is the detachment of core logic from UI. I suggest that you never write algorithms and stuff in window classes, rather have a generic class hold the data and multiple inherit the target window from the MFC window class the the generic class that holds the data. This way, you can repalce your windowing with say wxWindows easily because your window classes do not have any core implementation.
Thomas
My article on a reference-counted smart pointer that supports polymorphic objects and raw pointers
modified 29-Aug-18 21:01pm.
|
|
|
|
|
A thing to consider.
vector does not change its item count, if you do not use push_back or insert. Hence adding items with [] operator in a random manner after reserve is practically unusable.
But, CArray has a bigger problem. Once you do SetSize(), GetCount() always returns the size set by SetSize(). CArray is therefore a very close implementation to a C array, where as vector has a max_size and a size, max_size is the value you set with reserve. size represents the actual number of items you inserted into the vector.
Just observations that I made. Anyway, you can do the folllowing too, to speed up vector in your sample.
vector<int > vint;
vint.reserve(1000000);
int* p = &vint[0];
for (int i = 0; i < 1000000; ++i)
{
*(p + i) = i;
}
Using rand is also not correct. I would recommend leaving it out, because rand does not seem to be a constant time operation.
My article on a reference-counted smart pointer that supports polymorphic objects and raw pointers
modified 29-Aug-18 21:01pm.
|
|
|
|
|
CArray also has a size and max_size system. The problem is how it is exposed. CArray lacks the reserve and thus lacks some of the power of vector.
That vector initialization code won't work since you aren't updating the actual size of vector. However, if you used resize, it would work, but resize forces element contruction the same as CArray's SetSize.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
My point was:
If i declare a CArray and SetSize(), GetCount() and GetSize() returns the same value - the value set by SetSize(). Internally, the memory allocation for a SetAt is done just to cover the number of items required.
However, a vector allows me to reserve a size. Even if I don't reserve the insert causes a larger memory allocation, thereby not requiring resize, if I do not reserve.
Hence, if I want upto 150 items in a container and want to know how many items are there at a particular time, I use reserve(150) to reserve the maximum space and size() to get the actual number of params. The value returned by size is updated only if you use insert or push_back, and not the [] operator.
In a CArray, if i want to know the number of items that I added, i cannot find it if I used SetSize(). Instead, I have to rely on the default memory management of CArray which is to create memory for only the number of items that it needs.
vector can be used the same way by using reserve, and creating a pointer p that points to the start of the vector (T* p = &v[0]) and using p[i] to access the elements. But, there may be a number of free locations in between (CArray behaves the same way), there by eliminating the possibility of using any of the other STL algorithms.
SetSize() is similar to resize() and there is nothing corresponding to reserve(). The default memory allocation done when inserting a new item is better in vector, because it allocates more space so that subsequent inserts are faster.
My article on a reference-counted smart pointer that supports polymorphic objects and raw pointers
modified 29-Aug-18 21:01pm.
|
|
|
|
|
Using vector the way you talk about won't work since the destination objects have not been constructed. This normally isn't a problem for things such as int. But for a complicated class where you override the copy operator, the copy operator would have expected the destination to have been constructed. Using reserve and then accessing the elements through a pointer won't work properly.
This program shows why it doesn't work.
#include <assert.h>
#include <vector>
class test
{
public:
test ()
{
m_nInit = 1234567;
}
const test &operator = (const test &src)
{
assert (m_nInit == 1234567);
m_nInit = src .m_nInit;
return *this;
}
int m_nInit;
};
int main(int argc, char* argv[])
{
std::vector <test> v;
v .reserve (100);
test *p = &v [0];
p [0] = test ();
return 0;
}
Also, the size of the vector is never set. Thus "size" will always return 0 so the vector thinks it is empty. Doing a push_back will destroy the first element of the vector you just tried to initialize.
As for the other stuff. That is basically what I said. CArray lacks a reserve.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
OK guys, how about this:
CArray<int, int> IntArray; //make the array
IntArray.SetSize(0, 1000); //set the size to zero and the growby to 1000
int size = IntArray.GetSize(); //get the initial size
int upper_bound = IntArray.GetUpperBound(); //get the last element in the array
int random_limit = rand(); //create some random loop limit
for(int i = 0; i < random_limit; i++) //loop
IntArray.Add(rand()); //add random numbers to the array
size = IntArray.GetSize(); //check the size
upper_bound = IntArray.GetUpperBound(); //check where the last element is
The only thing that really bothers me is that you really can't tell if the 1000 elements have been allocated as SetAt() and ElementAt() ASSERT after m_nSize (returned by GetSize()).
Thanks,
John
|
|
|
|
|
You know, now that I come back and reread my last post, I realize that CArray has the m_nMaxSize member but it is protected. So, and I also realize you don't have to do this with vector but, subclassing CArray to expose that member would yield that result.
As far as the other functionality contained in vector I would like to test that aswell against what CArray can (be made to) do. Believe me though, I am not looking to reinvent the wheel or disprove the illustrious status of STL, I am curious and investigating possibilities.
Would anyone mind comming up with a examples of situations where using the features of the STL containers would come in handy? Should this be a new thread?
John
|
|
|
|
|
I created a full control with ATL 7.0. Somehow I couldn’t find it in the Insert ActiveX Control dialog box (either VS.NET, or 6). Is there something new in ATL 7.0? TIA.
|
|
|
|
|
Does anyone know if its safe to have a map of _variant_t like the one below?
std::map<DWORD, _variant_t> VAPMAP;
Thanks.
|
|
|
|
|
What are you worried about in terms of safety?
--Mike--
When 900 years old you reach, look as good you will not. Hmm.
1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click!
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
Any known problems really, and whether its a good idea in general.
|
|
|
|
|
Check if _variant_t overloads operator&. If it does, you may want to wrap it inside a CAdapt<> like this:
std::map<DWORD, CAdapt<_variant_t> >
I think it'll behave nice with _variant_t although it was designed for CComBSTR and some other class which I forget.
--
Only in a world this sh*tty could you even try to say these were innocent people and keep a straight face.
|
|
|
|
|
I am a VC MFC-based programmer, from now on I decided to work on WTL based apps., but before doing my hands dirty with this specification, I decided to plan a demo app.
I first developed a MFC-based Dialog app with MFC dynamically linked. Then I developed a WTL-based Dialog app with ActiveX hosting enabled.
After compiling both applications, I found WTL execuatable was heavy then MFC-based application. I know that due to dynamically linking the size reduces to minimum of MFC-based app. But when I ran Dependency Walker I found the SIZE of MFC-based and WTL-based applications were same (along with the dependencies). Plus the executable time were same.
Please anybody has some idea what was happening, as I found everywhere that WTL is lighting fast.
Rgds
Dammy More
|
|
|
|
|
Not sure what your question is. Statically link MFC to make a more accurate comparison (since the WTL, ATL, and CRT code is statically linked to WTL apps all the time*).
*Assuming you don't use the MinSize build configurations, which you shouldn't because using ATL.DLL is problematic due to different versions not being compatible.
--Mike--
When 900 years old you reach, look as good you will not. Hmm.
1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click!
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
|
Hi!!!
Suppose i develop a simple dialog based app in MFC using wizard and link MFC statically with it. On the other hand i develop the same application in WTL. Which package will be of smaller size ????
Actually i've heard the WTL based apps are of smaller size. But i experimented yesterday with both MFC dialog and ATL dialog. I sum the size of MFC based exe with all the dependencies. Then i sum the size of WTL exe with all its dependencies. What i noted is that the size remains same in both cases. Moreover the compilation time of WTL 7.0 based app, as i noticed was slow that the corresponding MFC based app. Are my observations correct ????
|
|
|
|
|
Shah Shehpori wrote:
Moreover the compilation time of WTL 7.0 based app, as i noticed was slow that the corresponding MFC based app. Are my observations correct ????
Just be sure you put all the WTL-includes in stdafx.h. I see no major difference in compile time between MFC and WTL.
As for the size: from what I've seen, WTL apps are in general smaller.
--
Only in a world this sh*tty could you even try to say these were innocent people and keep a straight face.
|
|
|
|
|
I'm having difficulty using this method, specifically...
lResult = reg.QueryStringValue("PathOut", regtext, sizeof(regtext));
It would be nice to see some examples using this CRegKey method or something. I can't seem to nail down the third parameter...
"The size, in TCHARs, of the buffer pointed to by pszValue. When the method returns, pnChars contains the size, in TCHARs, of the string retrieved, including a terminating null character."
TIA
Ryan
|
|
|
|
|
TCHAR szBuffer[128];
DWORD dwSize = sizeof(szBuffer) / sizeof(TCHAR);
lResult = reg.QueryStringValue ( _T("PathOut"), szBuffer, &dwSize );
--Mike--
When 900 years old you reach, look as good you will not. Hmm.
1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click!
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
