|
Yes you can use it.
1) If you create an application than one option for ATL i.e. "Add common header files for ATL" is displayed.If you select these than it automatically add this header for you.
or
2) You can use basic_string of STL, std::string, std::wstring as per your requirement.
I believe in LOVE AT FIRST SIGHT...
Bcoz I have loved my Mother...
even since I opened my eyes...(ICAN)
|
|
|
|
|
do std::wstring has trim function as CString have.
(Trim, LTrim, RTrim )
Some Day I Will Prove MySelf :: GOLD
|
|
|
|
|
No there is no built in functionality for trim in basic_string but you can make a function of it. Search on Google, you will get the better result
First link of google that have solution is :
Click here ->
I believe in LOVE AT FIRST SIGHT...
Bcoz I have loved my Mother...
even since I opened my eyes...(ICAN)
|
|
|
|
|
thanx nice 
Some Day I Will Prove MySelf :: GOLD
|
|
|
|
|
WC
I believe in LOVE AT FIRST SIGHT...
Bcoz I have loved my Mother...
even since I opened my eyes...(ICAN)
|
|
|
|
|
Indeed you may use CString in a Win32 application. However std::string might be a valid alternative.
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]
|
|
|
|
|
To begin, I'm enrolled a some programming classes at the my university, so I'm getting my C++ feet wet through experimentation. The following code generates a heap corruption error everytime I launch it.
#include<iostream>
using namespace std;
struct IntArray
{
int Iarray[0];
};
void main()
{
char end;
short num = 20;
IntArray* A = (IntArray*)new int(sizeof num);
for ( short i = 0 ; i < 10 ; ++i )
{
A->Iarray[i] = ( i * 10 );
}
for ( short j = 0 ; j < 10 ; ++j )
{
cout << A->Iarray[j]," ";
}
cin >> end;
delete A;
return;
}
This is the error that it generates before the program even starts to run:
"Windows has triggered a breakpoint in My Arrays.exe.
This may be due to a corruption of the heap, which indicates a bug in My Arrays.exe or any of the DLLs it has loaded.
This may also be due to the user pressing F12 while My Arrays2.exe has focus.
The output window may have more diagnostic information."
I following the exact procedures found in the MSDN article:
http://msdn.microsoft.com/en-us/library/0scy7z2d(VS.80).aspx
I'm trying to build array methods that I can understand.
Any idea on where I screwed this up will be helpful to the learning process.
|
|
|
|
|
Foothill wrote: IntArray* A = (IntArray*)new int(sizeof num);
Not sure why you are allocating memory for this from the heap. Since only one A is being used, just use:
IntArray A;
Foothill wrote: int Iarray[0];
This will only hold one int, not 10.
Foothill wrote: cout << A->Iarray[j]," ";
Perhaps you meant:
cout << A->Iarray[j] << " ";
"One man's wage rise is another man's price increase." - Harold Wilson
"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
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
I'm trying to dynamically resize arrays at runtime so that I can make a self-addaptable code to handle a variety of needs. This was just the initial attempt. As far as 'why from the heap?', the MSDS example was the first destination following my first attempts at this so if there are other ways, I would love to know about them. BTW, thanks for the syntax correction help, switching my brain from Visual Basic to C++ isn't as easy as I thought it would be.
|
|
|
|
|
Foothill wrote: I'm trying to dynamically resize arrays at runtime
With the CRT, there was the realloc() function. Otherwise, it's not much more difficult, you just have to do more yourself. For example:
int *x = new int[3];
x[0] = 2;
x[1] = 4;
x[2] = 6;
int *y = new int[5];
memcpy(y, x, 3 * sizeof(int));
y[3] = 8;
y[4] = 10;
delete [] x;
"One man's wage rise is another man's price increase." - Harold Wilson
"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
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
Perfect Answer 5 .
I love to read your answer because you explain the things perfectly
I believe in LOVE AT FIRST SIGHT...
Bcoz I have loved my Mother...
even since I opened my eyes...(ICAN)
|
|
|
|
|
Foothill wrote: I following the exact procedures found in the MSDN article:
http://msdn.microsoft.com/en-us/library/0scy7z2d(VS.80).aspx
Read it once, it is an example of "Compiler Error C2229".
The way David give is correct or you may use malloc and realloc.
I believe in LOVE AT FIRST SIGHT...
Bcoz I have loved my Mother...
even since I opened my eyes...(ICAN)
|
|
|
|
|
Everyting but this line:
IntArray* A = (IntArray*)new int(sizeof num);
looks to be ok. (Well, you might want to use num instead of 10 in your loops)
int *i = new int(n);
will allocate space for one int, and initialize it with the value of n. Your case is like this, where n = sizeof num which is the number of bytes in a short, typically 2. This is not much of an array, even though you may access it as a single element array.
On the other hand
int *a = new int[n];
will allocate space for n ints. If you change your line to
IntArray* A = (IntArray*)new int[num];
your code will be alright.
|
|
|
|
|
Foothill wrote: #include
is missing the filename to be included, e. g.
#include <io.h>
Foothill wrote: int Iarray[0];
This technically declares an array of 0 integers. However, I believe for some obscure reasons compilers are obliged to always allocate at least one element for an array, so in the end your struct will contain exactly one int. What you probably meant is (also see below):
int *Iarray;
Foothill wrote: IntArray* A = (IntArray*)new int(sizeof num);
As has been pointed out, this allocates memory for just one int and initializes it with 2. Also you are blindly casting the result of the allocation to IntArray*. You cannot equate the struct you defined with the array you defined within that struct even though the compiler will permit this.
First, sizeof delivers the size of the memory required to hold a variable of a particular type, in this case short. If you want the value that a variable holds, just write its name, num, instead.
Second, new takes several parameters, but it's syntax is special:
new int allocates memory for one variable of type int, and returns a pointer to its address.
new int(5) allocates memory for one variable of type int, and initializes it with the value 5, then returns a pointer to its address.
new int[5] allocates memory for a block of five variables of type int, and returns a pointer to the start of that block, holding the first element.
In all these cases, the return type is int*. So you could for instance assign any of the above expressions to A->Iarray, without the need for a type cast. The following line for example would allocate a block of 20 integers and assign its address to A->Iarray:
A->Iarray = new int[num];
However, that would assume you have a variable A of type struct IntArray, which you could dynamically allocate with
IntArray *A = new IntArray;
Of course, you could just as well define A as a local variable like this:
IntArray A;
You would need to write A.Iarray instead of A->Iarray then of course, since A is no longer declared as a pointer.
Foothill wrote: for ( short i = 0 ; i < 10 ; ++i )
You should use the correct limit for the loop, i. e. num instead of 10, assuming that you indeed correctly allocated an array of num elements.
Foothill wrote: cout << A->Iarray[j]," ";
The '<<' operator should be used for each element that you want to print out individually, until the end of the operation; writing cout << "hello " << "world"; will give you the same result as cout << "hello "; cout << "world";, but in the first case you need the second <<! What you probably wanted to write was
cout << A->Iarray[j] << ", ";
Foothill wrote: delete A;
With the incorrect use of new above, this line is correct, and nothing will happen. But if you correct your allocation statement as indicated above, you need to specifically tell the compiler that it is an array that you want to delete, not an individual object. You do this by using delete [] instead of delete:
delete [] A->Iarray;
Sorry to repeat some of the corrections already given, but I thought it won't hurt to put everything in one place. 
|
|
|
|
|
I think markup ate his header.
There are several cases where this type of allocation is of great help. E.g. when reading or writing a known binary representation of some object. I do this quite a lot, not allocating ints, but rather do it on a byte level. Your suggestion of allocating the array and assign it to A->Iarray will simply not work in those cases, since you need a consecutive chunk of memory too work with. Properly wrapped in classes, this means you can memory map a file, and use pointers straight into the data. The typical struct holds a count accompanying the array(s).
struct Point
{
double x, y;
};
struct Polyline
{
__int32 pointCount;
Point points[2];
};
I think dialog templates are handled like this too.
As you point out, the delete has to be done on the byte array rather than on the mapped struct type.
|
|
|
|
|
I understand your words, but I fail to see under which circumstances such a construct would be needed, and in what way my suggestion wouldn't work. The only difference would be the need for an additional 4 (or 8) bytes for the pointer variable. In return, you'll get a struct that actually does what the definition implies rather than one that will inexplicably fail on standard assignments.
[edit]
P.S.: just thought of an example that would indeed benefit from such a construct: memory allocation functions. You'd allocate a consecutive chunk of memory big enough to not only hold the array of data as requested, but also additional info (such as block size or debug info), then return the starting address of the array. Upon deletion, thanks to the consecutive block, you can manipulate the pointer to the array to access that additional information again.
In this case, the consecutive allocation serves as a means to store hidden information and later access it with no additional info required beyond the address of the user data.
Not something you couldn't also do with C++ constructs such as delegates, but that is what to my knowledge the debug implementation of new and delete do.
[/edit]
|
|
|
|
|
One example could be if you use CreateDialogIndirect, which accepts a CDLGTEMPLATEEX[^]* as one of its arguments. The size of this 'struct' cannot always be determined at compile time, since you could change a string value dynamically before creating the dialog.
The title character data is expected to be found at an offset from the start of the struct, and it's supposed to be zero-terminated, with the pointsize member following directly after (on a word boundary I suppose).
[edit about your edit]
That would indeed be one usage. Not one that I have tried, but a simple way to do buffer overflow checks I suppose, where you could put signature data around your memory block.
[/edit about your edit]
[edit]
Stefan63 wrote: not only hold the array of data as requested, but also additional info
This, of course, is the key issue. Maybe I wasn't very clear about that.
[/edit]
home
modified on Wednesday, February 16, 2011 4:47 AM
|
|
|
|
|
I'm not a compiler but since at compile time the compiler doesn't know the string contained in title, it would translate every reference to pointsize into an offset to the start of the struct, using titleLen as length for title. At runtime, the end of title might come long before the end of the reserved string, but the remaining bytes would just be unused.
Similarly, any assignment of this struct would copy the memory block using the size determined by titleLen and stringLen (which I take to be constants that are defined elsewhere).
Assuming your interpretation would be correct, and one of these structs would use a title of 4 characters length, whereas another was defined with a title of 20 characters length, then the second gets assigned to the first. Not only would you write past the boundaries of the memory block allocated for the first struct, you'd also invalidate any pointers to elements of the first struct that point to elements past title!
|
|
|
|
|
I know. There are ways to get around this. The easiest case is if the dynamic part is at the end of the struct. If not, you can split the struct into two parts, so each ends with a dynamically sized data, to match the binary signature. It's rather simple really as long as you know how to calculate the offsets properly.
Edit:
titleLen and stringLen are NOT constants, which is the whole point here.
home
modified on Wednesday, February 16, 2011 5:21 AM
|
|
|
|
|
I will try to explain this in a different way. Suppose you call a black box API with returns a pointer to a chunk of memory. According to the specifications, the first four bytes are an integer containing a version number of the data. After that there is a four byte unsigned integer giving how many samples you will get, followed by that many eight byte double float sample values.
In code that might look like:
void *data = GetSamples();
int version = * (int*) data;
unsigned int sampleCount = * (unsigned int*) (( (char*) data ) + sizeof(int))
double *samples = (double*) (( (char*) data ) + sizeof(int) + sizeof(unsigned int))
This will extract the variables needed, and they are now ready to be used. The way they are found is rather error prone.
A better way of doing this would be to map a known struct over the data with the same binary representation
struct Samples
{
int version;
unsigned int sampleCount;
double samples[];
};
void *data = GetSamples();
Samples *samples = (Samples*) data;
Now I can use samples as if it was a pointer to Samples. The good thing here is that the compiler will help me calculate the offsets for each known part of the binary data. This is the reverse of what I described in my earlier post.
Now assume there is another API which accepts such a set of binary data for processing, ProcessSamples(void* data); How would you construct the data if you only had the specification to it, and the data you had access to was in another format?
struct Samples
{
int version;
unsigned int sampleCount;
double samples[];
};
size_t dataSizeNeeded = sizeof(int) + sizeof(unsigned int) + sizeof(double) * mySampleCount;
char *bytes = new char[dataSizeNeeded]; Samples *samples = (Samples*) bytes;
samples->version = 1;
samples->sampleCount = mySampleCount;
for (size_t i = 0; i < mySampleCount; ++i)
{
samples->samples[i] = ...;
}
ProcessSamples(samples);
delete [] bytes;
The compiler will again help with the offsets, even though we're dealing with a 'dynamically sized struct'.
N.B. I intensionally left out important info on struct member alignment, Microsoft extensions to the C++ language, size of data types, data hiding, how to handle multiple dynamically sized members in the same 'struct', and the sample is not from the real world.
|
|
|
|
|
Thanks for your effort but I'm afraid it goes wasted. I totally understood what this is about, As I pointed out before, it's like what new and delete do, only that they're not bothering to define a struct. And, btw., CDLGTEMPLATEEX is probably worse than that, as not only is there no actual definition of that 'struct', some of it's members may be missing entirely! That's what confused me.
I still fail to see why it's better to hack a struct than just use pointers for the dynamic parts. That kind of coding was bad style in times before C++, and it's even worse nowadays. I'd put it on par with using goto, but that might do goto injustice. What we're talking about here is self-modifying data, and I don't see how that is any better than self-modifying code.
The only justification I can think of is some low level code that is really, and I mean REALLY keen to save the extra memory required for the pointer(s). For coding it makes no difference at all. For memory usage, you just need one additional pointer for the dynamically sized part. For efficiency, you only add one level of indirection for resolving access to elements of the dynamic part. In return you get clear data structures that describe what is actually there, remove the need to unsafe type-casting, and get code that is much more readable and maintainable.
IMHO, that MS is still using such techniques is an abomination. And it is no reason to use such techniques yourself.
|
|
|
|
|
It's not about saving the space required by a pointer. It's about the black box. If one could design it all from the beginning, this would never have been discussed. The problem is that one can't change the requirements a black box has. You can't change how Microsoft expects to receive the data for a binary dialog template. You can't redesign the structure.
Why would you want to deal with pointer arithmetics if the compiler can do it for you? Remember that this is about well defined binary representations only. Not data that will change depending on processor architecture or operating system version.
|
|
|
|
|
Niklas Lindquist wrote: If one could design it all from the beginning, this would never have been discussed.
My point exactly.
I am aware that you have to deal with it if you want to access MS's interfaces, and I understand why you would provide pseudo-definitions for the structures being used in that case.
But since the OP didn't do that there was no reason to use such a construct in the first place. Hence I suggested using a pointer instead.
|
|
|
|
|
Ok. In retrospect, I was reading more into the OP question than was really there. To me it looked as if it was a binary layout going on, which he later indicated there wasn't.
|
|
|
|
|
No worries. I did ask what such a construct would be good for, so I shouldn't have been surprised to receive an answer, even if it was unrelated to the original problem.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
