By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,669 Members | 1,645 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,669 IT Pros & Developers. It's quick & easy.

Returning a wstring from a method...

P: n/a
Hi,

I have a very simple function, declared like this:

wstring CMyClass::GetDate()
{
....
wcsftime (sDateString,255,L"%d-%b-%Y",&dTmpDate);
wstring sText(sDateString);
return sText;
}

I call it like this:

wstring myString = GetDate();

Nothing exciting there, but whever I run the program in debug mode I
get an Access Violation Error - "Access violation reading location
0xfdfdfdfd.". The error happens on the return line. The program seems
to run fine when I don't debug into it :(

Does anyone know what this could be? I'm using Microsoft VS2005 as the
IDE.

Thanks

Aug 11 '06 #1
Share this Question
Share on Google+
9 Replies


P: n/a
Mwob wrote:
Hi,

I have a very simple function, declared like this:

wstring CMyClass::GetDate()
{
....
wcsftime (sDateString,255,L"%d-%b-%Y",&dTmpDate);
wstring sText(sDateString);
return sText;
}
That's unlikely to compile, with the dots and no defintion of
sDateString.
I call it like this:

wstring myString = GetDate();

Nothing exciting there, but whever I run the program in debug mode I
get an Access Violation Error - "Access violation reading location
0xfdfdfdfd.". The error happens on the return line.
Typical error pattern written to memory after deallocation of an
object.
And of course, the return line is when local objects are destroyed.
The program seems to run fine when I don't debug into it :(
Might be because the error pattern isn't written in release mode. The
goal of the error pattern is so the application crashes as early as
possible,
which is good in debugging. It only slows the release build of your
app.

HTH,
Michiel Salters

Aug 11 '06 #2

P: n/a

Mwob wrote:
Hi,

I have a very simple function, declared like this:

wstring CMyClass::GetDate()
{
....
wcsftime (sDateString,255,L"%d-%b-%Y",&dTmpDate);
wstring sText(sDateString);
return sText;
}

I call it like this:

wstring myString = GetDate();

Nothing exciting there, but whever I run the program in debug mode I
get an Access Violation Error - "Access violation reading location
0xfdfdfdfd.". The error happens on the return line. The program seems
to run fine when I don't debug into it :(
It could be a problem with something in a watch-window or something
like that. I've had a similar problem with Visual Studio once (not
2005, though): closing some of the debug-windows removed the problem.

/Peter
>
Does anyone know what this could be? I'm using Microsoft VS2005 as the
IDE.

Thanks
Aug 11 '06 #3

P: n/a
Thanks for the response.

I'm a bit rusty with C++, its been a while since I revisted this page.
The dots were just entered by me to remove unesessary code that wasn't
relevent.

I'm not sure what to do here. Am I going about returning a wstring the
wrong way? Shoudl I structure the code differently? ..... I'll include
that class definiton again with more info this time:

wstring CInterval::GetDate(DateType retdate)
{
// First I declate a local string to hold my formatted date.
wchar_t sDateString[12];

// I then process some business rules, which I will ommit from
here...

// I then use a method to popupate with the date:
wcsftime (sDateString,255,L"%d-%b-%Y",&dTmpDate);

// Because I want to return a wstring, I instantiate one and pass the
// wchat_t in as a constructor
wstring sText(sDateString);

// Finally, I return that new string
return sText; // Here is where the error occurs
}

Should I be creating my method differently?

Thanks again for your help!
BTW - I tried closing all local debugging windows, that didn't help.
Mi*************@tomtom.com wrote:
Mwob wrote:
Hi,

I have a very simple function, declared like this:

wstring CMyClass::GetDate()
{
....
wcsftime (sDateString,255,L"%d-%b-%Y",&dTmpDate);
wstring sText(sDateString);
return sText;
}

That's unlikely to compile, with the dots and no defintion of
sDateString.
I call it like this:

wstring myString = GetDate();

Nothing exciting there, but whever I run the program in debug mode I
get an Access Violation Error - "Access violation reading location
0xfdfdfdfd.". The error happens on the return line.

Typical error pattern written to memory after deallocation of an
object.
And of course, the return line is when local objects are destroyed.
The program seems to run fine when I don't debug into it :(

Might be because the error pattern isn't written in release mode. The
goal of the error pattern is so the application crashes as early as
possible,
which is good in debugging. It only slows the release build of your
app.

HTH,
Michiel Salters
Aug 11 '06 #4

P: n/a
"Mwob" <ma*********@gmail.comwrote in message
news:11*********************@h48g2000cwc.googlegro ups.com...
: I'm not sure what to do here. Am I going about returning a wstring the
: wrong way? Shoudl I structure the code differently? ..... I'll include
: that class definiton again with more info this time:
:
: wstring CInterval::GetDate(DateType retdate)
: {
: // First I declate a local string to hold my formatted date.
: wchar_t sDateString[12];
:
: // I then process some business rules, which I will ommit from
: here...
:
: // I then use a method to popupate with the date:
: wcsftime (sDateString,255,L"%d-%b-%Y",&dTmpDate);
:
: // Because I want to return a wstring, I instantiate one and pass the
: // wchat_t in as a constructor
: wstring sText(sDateString);
:
: // Finally, I return that new string
: return sText; // Here is where the error occurs
This is all ok, although you could drop the intermediate
variable and directly write:
return sDateString;
: }
:
: Should I be creating my method differently?
Unless there is a bug in the implementation of wstring (very
unlikely), the only possible problem in the above code is
with the sDateString buffer: are 12 chars provably enough,
regarding of the locale? Try increasing the buffer size.

If this is not the culprit, then the problem is most likely
in the code fragments that you omitted from your post.
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form
Aug 11 '06 #5

P: n/a
Thanks.

Hmmm, I stripped the method right down so that it now only contains
this code (no ommitted code this time)

wstring CInterval::GetDate(DateType retdate)
{

wchar_t sDateString[100]; // Plenty of room in here
tm dTmpDate;
dTmpDate = dFrom; // This is a valid initialised "tm" structure.

wcsftime (sDateString,255,L"%d-%b-%Y",&dTmpDate);
wstring sText(sDateString);

return sText; // Still errors here!

}

This still falls over, even with a much bigger buffer (it shouldn't be
more that 12 chars in length) and all over code deleted from the
method!


Ivan Vecerina wrote:
"Mwob" <ma*********@gmail.comwrote in message
news:11*********************@h48g2000cwc.googlegro ups.com...
: I'm not sure what to do here. Am I going about returning a wstring the
: wrong way? Shoudl I structure the code differently? ..... I'll include
: that class definiton again with more info this time:
:
: wstring CInterval::GetDate(DateType retdate)
: {
: // First I declate a local string to hold my formatted date.
: wchar_t sDateString[12];
:
: // I then process some business rules, which I will ommit from
: here...
:
: // I then use a method to popupate with the date:
: wcsftime (sDateString,255,L"%d-%b-%Y",&dTmpDate);
:
: // Because I want to return a wstring, I instantiate one and pass the
: // wchat_t in as a constructor
: wstring sText(sDateString);
:
: // Finally, I return that new string
: return sText; // Here is where the error occurs
This is all ok, although you could drop the intermediate
variable and directly write:
return sDateString;
: }
:
: Should I be creating my method differently?
Unless there is a bug in the implementation of wstring (very
unlikely), the only possible problem in the above code is
with the sDateString buffer: are 12 chars provably enough,
regarding of the locale? Try increasing the buffer size.

If this is not the culprit, then the problem is most likely
in the code fragments that you omitted from your post.
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form
Aug 11 '06 #6

P: n/a
"Mwob" <ma*********@gmail.comschrieb:
wchar_t sDateString[100]; // Plenty of room in here
wcsftime (sDateString,255,L"%d-%b-%Y",&dTmpDate);
The "255" should be "sizeof(sDateString)/sizeof(wchar_t)".

T.M.
Aug 11 '06 #7

P: n/a
Of course it shoudl!

And thats fixed the error too :) Thanks very much for pointing that out
to me :)
Torsten Mueller wrote:
"Mwob" <ma*********@gmail.comschrieb:
wchar_t sDateString[100]; // Plenty of room in here
wcsftime (sDateString,255,L"%d-%b-%Y",&dTmpDate);

The "255" should be "sizeof(sDateString)/sizeof(wchar_t)".

T.M.
Aug 11 '06 #8

P: n/a
Mwob wrote:
Of course it shoudl!
Please read the information below.


Brian
--
Please don't top-post. Your replies belong following or interspersed
with properly trimmed quotes. See the majority of other posts in the
newsgroup, or the group FAQ list:
<http://www.parashift.com/c++-faq-lite/how-to-post.html>
Aug 11 '06 #9

P: n/a
In article <u3***********@shared-files.de>, de******@shared-files.de
says...
"Mwob" <ma*********@gmail.comschrieb:
wchar_t sDateString[100]; // Plenty of room in here
wcsftime (sDateString,255,L"%d-%b-%Y",&dTmpDate);

The "255" should be "sizeof(sDateString)/sizeof(wchar_t)".
Better still: sizeof(sDateString)/sizeof(sDateString[0])

For example, assume that your compiler defines wchar_t as 16 bits, but
you decide you want to be able to hold UCS-4 characters, so you change
sDatrString into:

unsigned long sDateString[100];

Of course, something like:

typedef wchar_t char_type;

which you could then change to:

typedef unsigned long char_type;

and as long as everything else referred to char_type instead of wchar_t,
life would be good. Of course, that's supposed to be the idea of wchar_t
in the first place, but (unfortunately) many compilers define it as a
16-bit type, which can be problematic.

--
Later,
Jerry.

The universe is a figment of its own imagination.
Aug 13 '06 #10

This discussion thread is closed

Replies have been disabled for this discussion.