memory address of *wchar_t


 DEVELOP > c-Plus-Plus > memory address of *wchar_t

LINK TO THIS PAGE  


rating :  0   |  0


  Page 1 of 1

1
 
Topic: DEVELOP > c-Plus-Plus
User: "DDD"
Date: 28 Jan 2008 02:46:15 AM
Object: memory address of *wchar_t
I have some codes:
w_char **sFieldsUri;
sFieldsUri = &(new w_char[2]);
w_char **sValFind = nsnull;
sValFind = &(new w_char[2]);
When I debug my program, I found the above code had some strange
things. sFieldsUri+1 is equal to sValFind+0.
But if I change the codes to the following:
w_char **sFieldsUri;
sFieldsUri = &(new w_char[2]);
for(int i=0; i<2; i++)
{
sFieldsUri[i] = new w_char[100];
}
w_char **sValFind = nsnull;
sValFind = &(new w_char[2]);
for(int i=0; i<2; i++)
{
sVal Find[i] = new w_char[100];
}
sFieldsUri+0, sFieldsUri+1, and sValFind+0, sValFind+1 are all
difference.
Thanks for all.
.

User: "Alf P. Steinbach"

Title: Re: memory address of *wchar_t 28 Jan 2008 03:01:44 AM
* DDD:

I have some codes:
w_char **sFieldsUri;
sFieldsUri = &(new w_char[2]);

w_char **sValFind = nsnull;
sValFind = &(new w_char[2]);

The above shouldn't compile even if 'w_char' was the name of a type.
You can't take the address of a built-in type rvalue.
As a novice, simply don't use raw pointers.
Cheers, & hth.,
- Alf
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
.

User: "Jim Langston"

Title: Re: memory address of *wchar_t 28 Jan 2008 10:10:35 AM
DDD wrote:

I have some codes:
w_char **sFieldsUri;

Okay, sFieldsUri is a pointer to a pointer to a w_char.

sFieldsUri = &(new w_char[2]);

new returns a pointer to the allocated memory. You are trying to get the
address of this pointer? wtf? I don't think this is what you really want
to do.
Now, if you wanted your sFieldsUri to pointer two two arrays of w_char,
first you need to allocate memory for the pointers themselves.
sFieldsUri = new w_char*[2];
Now sFieldsUri would point to to w_char pointers. Now you could allocate
the acutal memory for the w_chars.
sFieldsUri[0] = new w_char[somesize];
sFieldsUri[1] = new w_char[somesize];
Allocating memory this way is fairly confusing and one can get lost as to
where their pointers actually point. It is better to not use pointers if
you can. What is wrong with std::string?

w_char **sValFind = nsnull;
sValFind = &(new w_char[2]);

When I debug my program, I found the above code had some strange
things. sFieldsUri+1 is equal to sValFind+0.

But if I change the codes to the following:
w_char **sFieldsUri;
sFieldsUri = &(new w_char[2]);

for(int i=0; i<2; i++)
{
sFieldsUri[i] = new w_char[100];
}

w_char **sValFind = nsnull;
sValFind = &(new w_char[2]);

for(int i=0; i<2; i++)
{
sVal Find[i] = new w_char[100];
}
sFieldsUri+0, sFieldsUri+1, and sValFind+0, sValFind+1 are all
difference.
Thanks for all.

--
Jim Langston
tazmaster@rocketmail.com
.
User: "DDD"

Title: Re: memory address of *wchar_t 29 Jan 2008 08:03:05 PM
On Jan 29, 12:10=A0am, "Jim Langston" <tazmas...@rocketmail.com> wrote:

DDD wrote:

I have some codes:
=A0 =A0 =A0 =A0w_char **sFieldsUri;


Okay, sFieldsUri is a pointer to a pointer to a w_char.

=A0 =A0 =A0 =A0sFieldsUri =3D &(new w_char[2]);


new returns a pointer to the allocated memory. =A0You are trying to get th=

e

address of this pointer? =A0wtf? =A0I don't think this is what you really =

want

to do.

Now, if you wanted your sFieldsUri to pointer two two arrays of w_char,
first you need to allocate memory for the pointers themselves.

sFieldsUri =3D new w_char*[2];
Now sFieldsUri would point to to w_char pointers. =A0Now you could allocat=

e

the acutal memory for the w_chars.

sFieldsUri[0] =3D new w_char[somesize];
sFieldsUri[1] =3D new w_char[somesize];

Allocating memory this way is fairly confusing and one can get lost as to
where their pointers actually point. =A0It is better to not use pointers i=

f

you can. =A0What is wrong with std::string?



=A0 =A0 =A0 =A0w_char **sValFind =3D nsnull;
=A0 =A0 =A0 =A0sValFind =3D =A0&(new w_char[2]);


When I debug my program, I found the above code had some strange
things. sFieldsUri+1 is equal to sValFind+0.


But if I change the codes to the following:
=A0 =A0 =A0 =A0w_char **sFieldsUri;
=A0 =A0 =A0 =A0sFieldsUri =3D &(new w_char[2]);


=A0 =A0 =A0 =A0for(int i=3D0; i<2; i++)
=A0 =A0 =A0 =A0{
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sFieldsUri[i] =3D new w_char[100];
=A0 =A0 =A0 =A0}


=A0 =A0 =A0 =A0w_char **sValFind =3D nsnull;
=A0 =A0 =A0 =A0sValFind =3D =A0&(new w_char[2]);


=A0 =A0 =A0 =A0for(int i=3D0; i<2; i++)
=A0 =A0 =A0 =A0{
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sVal Find[i] =3D new w_char[100];
=A0 =A0 =A0 =A0}
sFieldsUri+0, =A0sFieldsUri+1, and sValFind+0, sValFind+1 are all
difference.
Thanks for all.


--
Jim Langston
tazmas...@rocketmail.com

Thank you very much, Jim. Yes, you are right. &(new w_char[2]) is not
I wanna get. And new w_char*[2] works well.
Last, I wanna say that &(new w_char[2]) works differently in debug and
release version, because sValFind =3D &(new w_char[2]) is a error, a
big error.
.



  Page 1 of 1

1
 


Related Articles
 

NEWER
pg.1232     pg.940     pg.716     pg.544     pg.412     pg.311     pg.234     pg.175     pg.130     pg.96     pg.70     pg.50     pg.35     pg.24     pg.16     pg.10     pg.6     pg.3     pg.1

OLDER