|
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 ommitted delete s 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.
Thank you for your patience in guiding the nooB!
MZR
|
|
|
|
|
Mike 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 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
|
|
|
|
|
Mike 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
|
|
|
|
|
Hello All,
I am trying to Export data in Excel From MySql DataBase.But How to Create Fields and Data of Table in Row and Colume Format.
Thanks
If you can think then I Can.
|
|
|
|
|
eg_Anubhava wrote: I am trying to Export data in Excel From MySql DataBase
This sentence does not make sense - but maybe it's just me...
Other than that, in what way is your question related to C/C++?
|
|
|
|
|
It's easy i m trying to export data from mysql to Excel.
So what is not sensable thing?
If you can think then I Can.
|
|
|
|
|
So which part are you having trouble with, getting data from Excel, or putting data into MySQL?
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
I have problem while inserting data in Excel From MYSQL.
If you can think then I Can.
|
|
|
|
|
Are you using Excel's COM interface (i.e., automation), or its ODBC driver?
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
Yes I am using ODBC Driver.
Thanks for reply
If you can think then I Can.
|
|
|
|
|
Are you using MFC?
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
Yes.
If you can think then I Can.
|
|
|
|
|
Then read up on the CRecordset class.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
Thanks for your best suggestion.
If you can think then I Can.
|
|
|
|
|
Hi,
Whether Windows WorkFlow foundation supports in C++,
if yes.. how to implement it?.
Ratheesh.
|
|
|
|
|
No. Learn C# instead.
Kevin
|
|
|
|
|
|
Hi Buddys,
i can able to get tue document date using api, but i want to display it in international format/ 24 hours format, when i change reginal setting it will displays, but i dont want to change the setting, how can i access this w/o make any changes. revert me with feasible solutions
|
|
|
|
|
kirankatta wrote: ...but i want to display it in international format/ 24 hours format...
So what's the problem? Are you using GetDateFormat() ?
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
I'm implementing a class to manage an array of objects created on the heap.. Something like:
class Manager {
public:
Manager(void);
~Manager(void);
Populate(LPVOID data);
Retreive(int index);
private:
myObject * objects;
int count;
} myObject needs to contain a char array and a BYTE array, both also on the heap. My first inclination was to use a STRUCT :
struct myObject {
char * szName;
byte * lpbData;
}; As I thought about it, though, it seemed memory clean-up would be easier if I made myObject a class with public members, initialize the values with a constructor, and let the destructor handle memory clean-up:
class myObject {
public:
myObject(char * name, BYTE * data, DWORD size) {
this->szName = new char[strlen(name)+1]; strcpy(this->szName, name, strlen(name);
this->lpbData = new BYTE[size]; memcpy(this->lpbData, data, size);
this->dwSize = size;
}
~myObject(void) { delete this->szName; delete this->lpbData; }
public:
char * szName;
BYTE * lpbData;
DWORD dwSize;
}; Performance is critical in this particular application, and I'm thinking there's probably more to consider in the class vs. struct than just what makes memory cleanup easiest for me in the other classes.
Can anybody offer some help, here, or point me in the direction of a reference that might help?
Thanks,
MZR
|
|
|
|
|
classes and structs are basically the same in C++. The only difference is that structs have default member accessibility public , while classes have private .
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Also, inheritance is public by default for structs and private by default for classes.
«_Superman_»
I love work. It gives me something to do between weekends.
|
|
|
|
|
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|