Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > can't convert from type A* to type B*

Reply
Thread Tools

can't convert from type A* to type B*

 
 
carl.eichert@gmail.com
Guest
Posts: n/a
 
      05-17-2013
I need to change DMapEntry:Data from a char* to a class DMapData that contains the original pointer but still be able to refer to &pData[offset] in DMapEntry without changing it. Is this possible?

#include "stdafx.h"

class DMapData {
char* pData;
public:
char* operator->() { return pData; }
char operator[](size_t offset) { return pData[offset]; }

friend class DMapEntry;
};

class DMapEntry {
char* pStr;
public:
DMapData pData;
/*----->*/ void getStr(size_t offset) { pStr = &pData[offset]; }
};

int _tmain(int argc, _TCHAR* argv[])
{
DMapEntry a;
return 0;
}

Carl
Lomita, CA

 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      05-17-2013
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> I need to change DMapEntry:Data from a char* to a class DMapData
> that contains the original pointer but still be able to refer to
> &pData[offset] in DMapEntry without changing it. Is this possible?
>
> #include "stdafx.h"


?

> class DMapData {
> char* pData;
> public:
> char* operator->() { return pData; }


Why return a char* here?

> char operator[](size_t offset) { return pData[offset]; }
>
> friend class DMapEntry;
> };
>
> class DMapEntry {
> char* pStr;
> public:
> DMapData pData;
> /*----->*/ void getStr(size_t offset) { pStr = &pData[offset]; }


You can't take the address of temporary return value.

Why prefix a member that doesn't return anything with get?

> };
>
> int _tmain(int argc, _TCHAR* argv[])


Yuck!

--
Ian Collins
 
Reply With Quote
 
 
 
 
Stuart
Guest
Posts: n/a
 
      05-17-2013
Carl Eichert wrote
>>> int _tmain(int argc, _TCHAR* argv[])


Ian Collins <(E-Mail Removed)> wrote:
>> Yuck!


On 05/17/2013, Juha Nieminen wrote:
> That's a completely valid function declaration (if _TCHAR has been
> declared somewhere.) What's so "yuck!" about it?


I think that you know perfectly well what is so "yuck" about it. It's
platform dependent code. Those readers that are not familiar with the
Windows platform will probably wonder what this strange "tmain" is
supposed to be, and whether the OP could _please_ post a compilable
example (or direct the question to a newsgroup that is dedicated to C++
with Visual Studio).

Of course, OP may not know what is so special about "tmain", so I have
to admit that "yuck" is probably not very accurate. Which is why I send
this reply.

Regards,
Stuart


 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      05-20-2013
On Friday, May 17, 2013 12:20:00 PM UTC+1, Juha Nieminen wrote:
> Ian Collins <(E-Mail Removed)> wrote:
> >> int _tmain(int argc, _TCHAR* argv[])


> > Yuck!


> That's a completely valid function declaration (if _TCHAR has been
> declared somewhere.) What's so "yuck!" about it?


Actually, it's not, at least not at namespace scope. The symbol
_tmain is in the implementation namespace (as is _TCHAR). In
this regard, Microsoft actually did the right thing, and avoided
poluting the users namespace. (Assuming that it *is* the
Microsoft extension, which seems a fairly safe bet.)

As for Yuck!... I'm tempted to say rather: another victim.
Except that in this case, I don't think Microsoft was actually
trying to anything wrong. They just didn't really that it
doesn't buy you anything; that just changing a typedef and
a function signature won't suddenly make a program handling
narrow characters Unicode compliant.

--
James
 
Reply With Quote
 
Tiib
Guest
Posts: n/a
 
      05-26-2013
On Monday, 27 May 2013 01:06:29 UTC+3, Andy Champ wrote:
> On 20/05/2013 14:07, James Kanze wrote:
> > Except that in this case, I don't think Microsoft was actually
> > trying to anything wrong. They just didn't really that it
> > doesn't buy you anything; that just changing a typedef and
> > a function signature won't suddenly make a program handling
> > narrow characters Unicode compliant.

>
> What Microsoft's funny TCHAR etc. do is let you, with care, write a
> program that will function in both narrow and unicode implementations.


Wasted care. Windows ansi functions (names with A at end) are
converting wrapper around unicode functions (names with W at end)
so "narrow" means overhead for no gain. IOW one of that "both"
is pointless if the other one works.
 
Reply With Quote
 
Nobody
Guest
Posts: n/a
 
      05-27-2013
On Sun, 26 May 2013 16:42:22 -0700, Öö Tiib wrote:

>> What Microsoft's funny TCHAR etc. do is let you, with care, write a
>> program that will function in both narrow and unicode implementations.

>
> Wasted care. Windows ansi functions (names with A at end) are
> converting wrapper around unicode functions (names with W at end)
> so "narrow" means overhead for no gain.


That is the case in current versions of Windows, but it wasn't always that
way. TCHAR originated when Microsoft was still selling versions of Windows
which didn't support Unicode. Binaries which use the W versions won't run
on 95/98/ME (at least, not without unicows.dll, which didn't appear on the
scene until after ME was released).

 
Reply With Quote
 
Tiib
Guest
Posts: n/a
 
      05-27-2013
On Monday, 27 May 2013 04:45:15 UTC+3, Nobody wrote:
> On Sun, 26 May 2013 16:42:22 -0700, Tiib wrote:
> >> What Microsoft's funny TCHAR etc. do is let you, with care, write a
> >> program that will function in both narrow and unicode implementations.

> >
> > Wasted care. Windows ansi functions (names with A at end) are
> > converting wrapper around unicode functions (names with W at end)
> > so "narrow" means overhead for no gain.

>
> That is the case in current versions of Windows, but it wasn't always that
> way. TCHAR originated when Microsoft was still selling versions of Windows
> which didn't support Unicode. Binaries which use the W versions won't run
> on 95/98/ME (at least, not without unicows.dll, which didn't appear on the
> scene until after ME was released).


Yes it was not always wasted care, however at current moment it lets you
to do something with care that is basically wasted care.

Even Microsoft itself agrees: "The TEXT and TCHAR macros are less useful today,
because all applications should use Unicode. However, you might see them
in older code and in some of the MSDN code examples."
http://msdn.microsoft.com/en-us/libr...8VS.85%29.aspx
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      05-29-2013
On Sunday, May 26, 2013 11:06:29 PM UTC+1, Andy Champ wrote:
> On 20/05/2013 14:07, James Kanze wrote:
> > Except that in this case, I don't think Microsoft was actually
> > trying to anything wrong. They just didn't really that it
> > doesn't buy you anything; that just changing a typedef and
> > a function signature won't suddenly make a program handling
> > narrow characters Unicode compliant.

>
> What Microsoft's funny TCHAR etc. do is let you, with care, write a
> program that will function in both narrow and unicode implementations.


What Microsoft's funny TCHAR, etc. do is give you the illusion
that you can write a program that will function in both narrow
and wide character implementations. (Most of the code I write
today is narrow character, but fully supports Unicode. There's
no real relationship between the width of the character type and
whether it is Unicode or not.)

And it very defitety is an illusion, since the wide character
version of TCHAR is UTF-16, which requires special handling for
surrogates, etc.

--
James
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      05-29-2013
On Monday, May 27, 2013 3:39:11 AM UTC+1, Tiib wrote:
> On Monday, 27 May 2013 04:45:15 UTC+3, Nobody wrote:
> > On Sun, 26 May 2013 16:42:22 -0700, Tiib wrote:
> > >> What Microsoft's funny TCHAR etc. do is let you, with care, write a
> > >> program that will function in both narrow and unicode implementations.


> > > Wasted care. Windows ansi functions (names with A at end) are
> > > converting wrapper around unicode functions (names with W at end)
> > > so "narrow" means overhead for no gain.


> > That is the case in current versions of Windows, but it wasn't always that
> > way. TCHAR originated when Microsoft was still selling versions of Windows
> > which didn't support Unicode. Binaries which use the W versions won't run
> > on 95/98/ME (at least, not without unicows.dll, which didn't appear on the
> > scene until after ME was released).


> Yes it was not always wasted care, however at current moment it lets you
> to do something with care that is basically wasted care.


> Even Microsoft itself agrees: "The TEXT and TCHAR macros are less useful today,
> because all applications should use Unicode. However, you might see them
> in older code and in some of the MSDN code examples."
> http://msdn.microsoft.com/en-us/libr...8VS.85%29.aspx


It's interesting that I write a lot of code which supports
Unicode, but never uses anything other than char. As I said, I
think this is a case of Microsoft trying to do the right thing,
but not understanding all of the real issues. Anyone concerned
with internationalization, be it under Windows or under Unix,
will use UTF-8 on plain char at the external interface, and
depending on what they are doing inside the code, either UTF-8
or UTF-32 (on uint_least32_t, or char32_t if they have C++11).

--
James
 
Reply With Quote
 
Balog Pal
Guest
Posts: n/a
 
      05-29-2013
On 5/29/2013 11:50 PM, James Kanze wrote:
>
> What Microsoft's funny TCHAR, etc. do is give you the illusion
> that you can write a program that will function in both narrow
> and wide character implementations. (Most of the code I write
> today is narrow character, but fully supports Unicode. There's
> no real relationship between the width of the character type and
> whether it is Unicode or not.)
>
> And it very defitety is an illusion, since the wide character
> version of TCHAR is UTF-16, which requires special handling for
> surrogates, etc.


At the time the idea born it was UCS2 and surrogates considered not
worth bothering with. Eventually the latter fell, leaving behind a
system that puts together all the disadvantages without any of the
benefits... Well.

On the bright side, a C++ program is not forced to use the _UNICODE
model, the API functions and even many classes van be called with A or W
postfix, mixed and matched.


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Is there any way to get the raw image data from a Nikon Coolpix S8200 P&S camera? Tony Cooper Digital Photography 16 04-17-2013 07:49 PM
From IrfanView to Desktop wallpaper? Terry Pinnell Digital Photography 5 04-10-2013 11:11 PM
Re: retrieving data from a plot in python. Gary Herron Python 0 04-09-2013 06:00 PM
retrieving data from a plot in python. Debashish Saha Python 1 04-09-2013 05:58 PM
when I read gzipped response from web-servers, GzipReader returnssometimes 'invalid compressed data -- crc error' henry.jykim@gmail.com Ruby 0 04-08-2013 03:51 PM



Advertisments