Speaking of missing the basics - is there a way to dynamically size an array on the stack ?
-
I know that it works on the heap...
char * sz1 = "Text";
char * sz = new char[strlen(sz1)];...and I know that this will give me an error saying that a constant is expected:
char * sz1 = "Text";
char sz[strlen(sz1)];...So is there some other way to create an array on the stack whose size is not hard-coded ? I've seen things like:
char char * szBuff[iSomeLargeNumber];
char * sz1 = "Text";
strcpy(szBuff, sz1);But no matter how large
iSomeLargeNumberis, there's still a hard-coded limit... and declaring a large array on the stack uses the full amount of memory even if the full array isn't populated...(right?) Is the heap the only answer? As always, thanks for putting up with the nooB.. MZR -
I know that it works on the heap...
char * sz1 = "Text";
char * sz = new char[strlen(sz1)];...and I know that this will give me an error saying that a constant is expected:
char * sz1 = "Text";
char sz[strlen(sz1)];...So is there some other way to create an array on the stack whose size is not hard-coded ? I've seen things like:
char char * szBuff[iSomeLargeNumber];
char * sz1 = "Text";
strcpy(szBuff, sz1);But no matter how large
iSomeLargeNumberis, there's still a hard-coded limit... and declaring a large array on the stack uses the full amount of memory even if the full array isn't populated...(right?) Is the heap the only answer? As always, thanks for putting up with the nooB.. MZR -
I know that it works on the heap...
char * sz1 = "Text";
char * sz = new char[strlen(sz1)];...and I know that this will give me an error saying that a constant is expected:
char * sz1 = "Text";
char sz[strlen(sz1)];...So is there some other way to create an array on the stack whose size is not hard-coded ? I've seen things like:
char char * szBuff[iSomeLargeNumber];
char * sz1 = "Text";
strcpy(szBuff, sz1);But no matter how large
iSomeLargeNumberis, there's still a hard-coded limit... and declaring a large array on the stack uses the full amount of memory even if the full array isn't populated...(right?) Is the heap the only answer? As always, thanks for putting up with the nooB.. MZRYou could use
char * sz1 = "Text";
char* sz = (char*)_alloca(strlen(sz1));but make sure you don't exhaust available stack space (starts at 1MB and decreases for standard Windows threads). These days, Microsoft want you to use _malloca[^] instead - it's more safe apparently.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
I know that it works on the heap...
char * sz1 = "Text";
char * sz = new char[strlen(sz1)];...and I know that this will give me an error saying that a constant is expected:
char * sz1 = "Text";
char sz[strlen(sz1)];...So is there some other way to create an array on the stack whose size is not hard-coded ? I've seen things like:
char char * szBuff[iSomeLargeNumber];
char * sz1 = "Text";
strcpy(szBuff, sz1);But no matter how large
iSomeLargeNumberis, there's still a hard-coded limit... and declaring a large array on the stack uses the full amount of memory even if the full array isn't populated...(right?) Is the heap the only answer? As always, thanks for putting up with the nooB.. MZRIn addition, you've don't have to free pointer allocated using _alloca or _malloca because stack will cleared when the function is returned.
-Sarath. "Great hopes make everything great possible" - Benjamin Franklin
My blog - Sharing My Thoughts
-
I know that it works on the heap...
char * sz1 = "Text";
char * sz = new char[strlen(sz1)];...and I know that this will give me an error saying that a constant is expected:
char * sz1 = "Text";
char sz[strlen(sz1)];...So is there some other way to create an array on the stack whose size is not hard-coded ? I've seen things like:
char char * szBuff[iSomeLargeNumber];
char * sz1 = "Text";
strcpy(szBuff, sz1);But no matter how large
iSomeLargeNumberis, there's still a hard-coded limit... and declaring a large array on the stack uses the full amount of memory even if the full array isn't populated...(right?) Is the heap the only answer? As always, thanks for putting up with the nooB.. MZR...though that 1mb limit is rather unfortunate, for my current project. I'll have to use the heap after all, but it's a good thing to know for the future. MZR
-
...though that 1mb limit is rather unfortunate, for my current project. I'll have to use the heap after all, but it's a good thing to know for the future. MZR
You can change the default stack size from the project properties. Project Properties -> Configuration Properties -> Linker -> System -> Stack Reserve Size / Stack Commit Size. Look at the documentation for the /STACK[^] linker option.
«_Superman_» I love work. It gives me something to do between weekends.
-
I know that it works on the heap...
char * sz1 = "Text";
char * sz = new char[strlen(sz1)];...and I know that this will give me an error saying that a constant is expected:
char * sz1 = "Text";
char sz[strlen(sz1)];...So is there some other way to create an array on the stack whose size is not hard-coded ? I've seen things like:
char char * szBuff[iSomeLargeNumber];
char * sz1 = "Text";
strcpy(szBuff, sz1);But no matter how large
iSomeLargeNumberis, there's still a hard-coded limit... and declaring a large array on the stack uses the full amount of memory even if the full array isn't populated...(right?) Is the heap the only answer? As always, thanks for putting up with the nooB.. MZRI think this is not going in the stack but rather in the string table. My advice is to avoid this approach.
The narrow specialist in the broad sense of the word is a complete idiot in the narrow sense of the word. Advertise here – minimum three posts per day are guaranteed.
-
I know that it works on the heap...
char * sz1 = "Text";
char * sz = new char[strlen(sz1)];...and I know that this will give me an error saying that a constant is expected:
char * sz1 = "Text";
char sz[strlen(sz1)];...So is there some other way to create an array on the stack whose size is not hard-coded ? I've seen things like:
char char * szBuff[iSomeLargeNumber];
char * sz1 = "Text";
strcpy(szBuff, sz1);But no matter how large
iSomeLargeNumberis, there's still a hard-coded limit... and declaring a large array on the stack uses the full amount of memory even if the full array isn't populated...(right?) Is the heap the only answer? As always, thanks for putting up with the nooB.. MZRAre you really sure you want to allocate large chunks of data on the stack? Off the top of my head I can't think of any really good reason for doing this, and it seems to be more trouble than it's worth compared to heap allocation.
There are three kinds of people in the world - those who can count and those who can't...
-
Are you really sure you want to allocate large chunks of data on the stack? Off the top of my head I can't think of any really good reason for doing this, and it seems to be more trouble than it's worth compared to heap allocation.
There are three kinds of people in the world - those who can count and those who can't...
I'm writing an ISAPI extension to handle form data including one or more file uploads. Most of what I've read on ISAPI extensions has indicated that time and memory are of the essence, and, because of that, using the heap should be avoided, as much as is reasonable, in favor of using the stack. I understand a few parts of the stack/heap concept, but my knowledge (and understanding) is severly lacking in this area. As such, I didn't know whether or not trying to place the entire HTTP-REQUEST (including the uploaded files) on the stack was possible or reasonable until I asked. That said, when I asked about dynamically sizing an array I was more thinking about "standard-length" strings... I have been programming for several years, but, until the past couple years, almost exclusively in higher-level languages that didn't require me to keep track of memory. And, when I started with C++, I was using managed C++ with its garbage-collection crutch. Now that I'm trying (or having) to ditch the
__gc, I try to keep things on the stack as much as possible. Tracking down those ommitteddeletes is a pain, especially for often-changed member variables where I tend to forget todeletethe existing object/value before creating thenewone. Thank you for your patience in guiding the nooB! MZR -
I'm writing an ISAPI extension to handle form data including one or more file uploads. Most of what I've read on ISAPI extensions has indicated that time and memory are of the essence, and, because of that, using the heap should be avoided, as much as is reasonable, in favor of using the stack. I understand a few parts of the stack/heap concept, but my knowledge (and understanding) is severly lacking in this area. As such, I didn't know whether or not trying to place the entire HTTP-REQUEST (including the uploaded files) on the stack was possible or reasonable until I asked. That said, when I asked about dynamically sizing an array I was more thinking about "standard-length" strings... I have been programming for several years, but, until the past couple years, almost exclusively in higher-level languages that didn't require me to keep track of memory. And, when I started with C++, I was using managed C++ with its garbage-collection crutch. Now that I'm trying (or having) to ditch the
__gc, I try to keep things on the stack as much as possible. Tracking down those ommitteddeletes is a pain, especially for often-changed member variables where I tend to forget todeletethe existing object/value before creating thenewone. Thank you for your patience in guiding the nooB! MZRMike the Red wrote:
I try to keep things on the stack as much as possible.
That's reasonable. The general maxim in C++ is to use the stack except when you need to use the heap. :)
Mike the Red wrote:
Tracking down those ommitted deletes is a pain, especially for often-changed member variables where I tend to forget to delete the existing object/value before creating the new one.
Unless you have certain constraints within ISAPI (I'm not familiar with it) you should use Standard C++ (STL) and Boost to help you with such matters, i.e., avoid raw new and delete. However, there is a learning curve and I don't know how long you've been doing C++ for. For arrays you could use the STL vector. Then you don't need to worry about new and delete for dynamically sizing the array.
Kevin
-
I'm writing an ISAPI extension to handle form data including one or more file uploads. Most of what I've read on ISAPI extensions has indicated that time and memory are of the essence, and, because of that, using the heap should be avoided, as much as is reasonable, in favor of using the stack. I understand a few parts of the stack/heap concept, but my knowledge (and understanding) is severly lacking in this area. As such, I didn't know whether or not trying to place the entire HTTP-REQUEST (including the uploaded files) on the stack was possible or reasonable until I asked. That said, when I asked about dynamically sizing an array I was more thinking about "standard-length" strings... I have been programming for several years, but, until the past couple years, almost exclusively in higher-level languages that didn't require me to keep track of memory. And, when I started with C++, I was using managed C++ with its garbage-collection crutch. Now that I'm trying (or having) to ditch the
__gc, I try to keep things on the stack as much as possible. Tracking down those ommitteddeletes is a pain, especially for often-changed member variables where I tend to forget todeletethe existing object/value before creating thenewone. Thank you for your patience in guiding the nooB! MZRI do not pretend to be an ISAPI expert, but you're trying to get into some kind of hand-crafted memory management. This can be more dangerous than you imagine. Try using some of those existing and well tested libraries like stl, mfc, etc., Agreed that utilising the stack as much as possible is a good thing, but I don't think that it is going to make *that much* of a difference on any normal application. If you try pushing the stack to its limits, there's also a danger of stack overflow. I'll humbly suggest you to drop this idea of 'manual' memory management adventure. For all the pain that it could cause, it isn't worth. Frequent allocation and deallocation of the heap can fragment it and there are memory damage possibilities, memory leaks, etc., I won't ever choose something of this sort, unless I'm writing a memory manager or something like that myself. Pick an existing library and it would use the heap in the best possible way for you.
It is a crappy thing, but it's life -^ Carlo Pallini
-
I'm writing an ISAPI extension to handle form data including one or more file uploads. Most of what I've read on ISAPI extensions has indicated that time and memory are of the essence, and, because of that, using the heap should be avoided, as much as is reasonable, in favor of using the stack. I understand a few parts of the stack/heap concept, but my knowledge (and understanding) is severly lacking in this area. As such, I didn't know whether or not trying to place the entire HTTP-REQUEST (including the uploaded files) on the stack was possible or reasonable until I asked. That said, when I asked about dynamically sizing an array I was more thinking about "standard-length" strings... I have been programming for several years, but, until the past couple years, almost exclusively in higher-level languages that didn't require me to keep track of memory. And, when I started with C++, I was using managed C++ with its garbage-collection crutch. Now that I'm trying (or having) to ditch the
__gc, I try to keep things on the stack as much as possible. Tracking down those ommitteddeletes is a pain, especially for often-changed member variables where I tend to forget todeletethe existing object/value before creating thenewone. Thank you for your patience in guiding the nooB! MZRMike the Red wrote:
using the heap should be avoided, as much as is reasonable
I think > than around 10kB of allocation probably crosses the boundary of reasonable and unreasonable avoidance of heap usage :-)
Mike the Red wrote:
Tracking down those ommitted deletes is a pain, especially for often-changed member variables where I tend to forget to delete the existing object/value before creating the new one
If you're using VC2008, then std::tr1::shared_ptr[^] is handy. If not (or even if you are - see shared_array), then Boost.SmartPointers[^] is handy. The best advice is to wrap resource allocation/deallocation in an object[^] (allocation in constructors, deallocation in the destructor), so you can tie the resource usage to the object's lifetime. That's how the STL containers (vector, list, map, set etc) work. C++ (when written in a nice idiomatic way) relies on deterministic destruction to manage resources - when done right, it makes programming as easy as using garbage collection, IMO.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
...though that 1mb limit is rather unfortunate, for my current project. I'll have to use the heap after all, but it's a good thing to know for the future. MZR