Thread: [GD-General] Offset a void pointer
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-general
|
From: CAVEY G. <GER...@sg...> - 2004-10-12 12:16:07
|
Hi I have little question It seems impossible to me to offset a void pointer with the += operator can someone explain me why ? I don t really understand the compiler here ... the left casting should give him the memory unit size , right?Is left casting forbidden? void *BufferPtr; unnsigned int stridde=5; //doesnt compile ! (char*)BufferPtr+=stride; //will compile BufferPtr=(char*)BufferPtr+stride; Thanks GC. ************************************************************************* Ce message et toutes les pieces jointes (ci-apres le "message") sont confidentiels et etablis a l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisee est interdite. Tout message electronique est susceptible d'alteration. SG Asset Management et ses filiales declinent toute responsabilite au titre de ce message s'il a ete altere, deforme ou falsifie. Decouvrez l'offre et les services de SG Asset Management sur le site www.sgam.fr ******** This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. E-mails are susceptible to alteration. Neither SG Asset Management nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. ************************************************************************* |
|
From: Aaron D. <ri...@in...> - 2004-10-12 13:46:38
|
The cast has the same precedence as other unary operators. http://web.ics.purdue.edu/~cs240/misc/operators.html In no specific order: ++ -- + - ! ~ & * (type_name) sizeof new delete On Tue, 12 Oct 2004 10:17 pm, CAVEY GERARD wrote: > Hi > > I have little question > It seems impossible to me to offset a void pointer with the += operator > can someone explain me why ? > I don t really understand the compiler here ... the left casting should > give him the memory unit size , right?Is left casting forbidden? > > void *BufferPtr; > unnsigned int stridde=5; > //doesnt compile ! > (char*)BufferPtr+=stride; > //will compile > BufferPtr=(char*)BufferPtr+stride; > > Thanks > GC. > > > ************************************************************************* > Ce message et toutes les pieces jointes (ci-apres le "message") sont > confidentiels et etablis a l'intention exclusive de ses destinataires. > Toute utilisation ou diffusion non autorisee est interdite. > Tout message electronique est susceptible d'alteration. > SG Asset Management et ses filiales declinent toute responsabilite au titre > de ce message s'il a ete altere, deforme ou falsifie. > > Decouvrez l'offre et les services de SG Asset Management sur le site > www.sgam.fr > > ******** > > This message and any attachments (the "message") are confidential and > intended solely for the addressees. > Any unauthorised use or dissemination is prohibited. > E-mails are susceptible to alteration. > Neither SG Asset Management nor any of its subsidiaries or affiliates shall > be liable for the message if altered, changed or falsified. > > ************************************************************************* > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Gamedevlists-general mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=557 -- - Aaron "Today's mighty oak is just yesterday's nut that held its ground." |
|
From: Jorrit T. <jor...@uz...> - 2004-10-12 13:54:41
|
CAVEY GERARD wrote: >Hi > >I have little question >It seems impossible to me to offset a void pointer with the += operator >can someone explain me why ? >I don t really understand the compiler here ... the left casting should >give him the memory unit size , right?Is left casting forbidden? > >void *BufferPtr; >unnsigned int stridde=5; >//doesnt compile ! >(char*)BufferPtr+=stride; >//will compile >BufferPtr=(char*)BufferPtr+stride; > > Indeed, the cast operator is not an lvalue. So you cannot use it on the left side of an '=' like that. Greetings, |
|
From: Richard F. <ra...@gm...> - 2004-10-12 15:33:37
|
just add an ampersand to your cast to make it a reference pointer not just a pointer void *BufferPtr; unnsigned int stride=5; // should now compile (char*&)BufferPtr+=stride; On Tue, 12 Oct 2004 14:17:14 +0200, CAVEY GERARD <ger...@sg...> wrote: > Hi > > I have little question > It seems impossible to me to offset a void pointer with the += operator > can someone explain me why ? > I don t really understand the compiler here ... the left casting should > give him the memory unit size , right?Is left casting forbidden? > > void *BufferPtr; > unnsigned int stridde=5; > //doesnt compile ! > (char*)BufferPtr+=stride; > //will compile > BufferPtr=(char*)BufferPtr+stride; > > Thanks > GC. > > ************************************************************************* > Ce message et toutes les pieces jointes (ci-apres le "message") sont > confidentiels et etablis a l'intention exclusive de ses destinataires. > Toute utilisation ou diffusion non autorisee est interdite. > Tout message electronique est susceptible d'alteration. > SG Asset Management et ses filiales declinent toute responsabilite au titre > de ce message s'il a ete altere, deforme ou falsifie. > > Decouvrez l'offre et les services de SG Asset Management sur le site > www.sgam.fr > > ******** > > This message and any attachments (the "message") are confidential and > intended solely for the addressees. > Any unauthorised use or dissemination is prohibited. > E-mails are susceptible to alteration. > Neither SG Asset Management nor any of its subsidiaries or affiliates shall > be liable for the message if altered, changed or falsified. > > ************************************************************************* > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Gamedevlists-general mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=557 > |
|
From: Dan T. <da...@ar...> - 2004-10-12 17:08:18
|
Is there any problem with: BufferPtr = (char*)BufferPtr + stride; ? Compiles for me... certainly easier to read than (char*&)BufferPtr. Is one subtly faster than the in a way I'm not aware? -Dan Richard Fabian wrote: >just add an ampersand to your cast to make it a reference pointer not >just a pointer > >void *BufferPtr; >unnsigned int stride=5; >// should now compile >(char*&)BufferPtr+=stride; > > >On Tue, 12 Oct 2004 14:17:14 +0200, CAVEY GERARD <ger...@sg...> wrote: > > >>Hi >> >>I have little question >>It seems impossible to me to offset a void pointer with the += operator >>can someone explain me why ? >>I don t really understand the compiler here ... the left casting should >>give him the memory unit size , right?Is left casting forbidden? >> >>void *BufferPtr; >>unnsigned int stridde=5; >>//doesnt compile ! >>(char*)BufferPtr+=stride; >>//will compile >>BufferPtr=(char*)BufferPtr+stride; >> >>Thanks >>GC. >> >>************************************************************************* >>Ce message et toutes les pieces jointes (ci-apres le "message") sont >>confidentiels et etablis a l'intention exclusive de ses destinataires. >>Toute utilisation ou diffusion non autorisee est interdite. >>Tout message electronique est susceptible d'alteration. >>SG Asset Management et ses filiales declinent toute responsabilite au titre >>de ce message s'il a ete altere, deforme ou falsifie. >> >>Decouvrez l'offre et les services de SG Asset Management sur le site >>www.sgam.fr >> >> ******** >> >>This message and any attachments (the "message") are confidential and >>intended solely for the addressees. >>Any unauthorised use or dissemination is prohibited. >>E-mails are susceptible to alteration. >>Neither SG Asset Management nor any of its subsidiaries or affiliates shall >>be liable for the message if altered, changed or falsified. >> >>************************************************************************* >> >>------------------------------------------------------- >>This SF.net email is sponsored by: IT Product Guide on ITManagersJournal >>Use IT products in your business? Tell us what you think of them. Give us >>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more >>http://productguide.itmanagersjournal.com/guidepromo.tmpl >>_______________________________________________ >>Gamedevlists-general mailing list >>Gam...@li... >>https://lists.sourceforge.net/lists/listinfo/gamedevlists-general >>Archives: >>http://sourceforge.net/mailarchive/forum.php?forum_id=557 >> >> >> > > >------------------------------------------------------- >This SF.net email is sponsored by: IT Product Guide on ITManagersJournal >Use IT products in your business? Tell us what you think of them. Give us >Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more >http://productguide.itmanagersjournal.com/guidepromo.tmpl >_______________________________________________ >Gamedevlists-general mailing list >Gam...@li... >https://lists.sourceforge.net/lists/listinfo/gamedevlists-general >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_id=557 > > > > |
|
From: Richard F. <ra...@gm...> - 2004-10-13 09:24:46
|
i assume its not faster, but i personally think its better C++ (activley using these kinds of thing keeps your mind where it needs to be to think out better solutions to more complex problems) for example, I use ampersand suffixed return values for my container classes that implement operator[]. that way you can assign stuff to indexes. so really it just boils down to what you're comfortable with, with te caveat that maybe you should be comfortable with using cast to lvalue. On Tue, 12 Oct 2004 10:04:35 -0700, Dan Thompson <da...@ar...> wrote: > Is there any problem with: > > BufferPtr = (char*)BufferPtr + stride; > > ? Compiles for me... certainly easier to read than (char*&)BufferPtr. Is > one subtly faster than the in a way I'm not aware? > > -Dan > > > > > Richard Fabian wrote: > > >just add an ampersand to your cast to make it a reference pointer not > >just a pointer > > > >void *BufferPtr; > >unnsigned int stride=5; > >// should now compile > >(char*&)BufferPtr+=stride; > > > > > >On Tue, 12 Oct 2004 14:17:14 +0200, CAVEY GERARD <ger...@sg...> wrote: > > > > > >>Hi > >> > >>I have little question > >>It seems impossible to me to offset a void pointer with the += operator > >>can someone explain me why ? > >>I don t really understand the compiler here ... the left casting should > >>give him the memory unit size , right?Is left casting forbidden? > >> > >>void *BufferPtr; > >>unnsigned int stridde=5; > >>//doesnt compile ! > >>(char*)BufferPtr+=stride; > >>//will compile > >>BufferPtr=(char*)BufferPtr+stride; > >> > >>Thanks > >>GC. > >> > >>************************************************************************* > >>Ce message et toutes les pieces jointes (ci-apres le "message") sont > >>confidentiels et etablis a l'intention exclusive de ses destinataires. > >>Toute utilisation ou diffusion non autorisee est interdite. > >>Tout message electronique est susceptible d'alteration. > >>SG Asset Management et ses filiales declinent toute responsabilite au titre > >>de ce message s'il a ete altere, deforme ou falsifie. > >> > >>Decouvrez l'offre et les services de SG Asset Management sur le site > >>www.sgam.fr > >> > >> ******** > >> > >>This message and any attachments (the "message") are confidential and > >>intended solely for the addressees. > >>Any unauthorised use or dissemination is prohibited. > >>E-mails are susceptible to alteration. > >>Neither SG Asset Management nor any of its subsidiaries or affiliates shall > >>be liable for the message if altered, changed or falsified. > >> > >>************************************************************************* > >> > >>------------------------------------------------------- > >>This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > >>Use IT products in your business? Tell us what you think of them. Give us > >>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more > >>http://productguide.itmanagersjournal.com/guidepromo.tmpl > >>_______________________________________________ > >>Gamedevlists-general mailing list > >>Gam...@li... > >>https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > >>Archives: > >>http://sourceforge.net/mailarchive/forum.php?forum_id=557 > >> > >> > >> > > > > > >------------------------------------------------------- > >This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > >Use IT products in your business? Tell us what you think of them. Give us > >Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more > >http://productguide.itmanagersjournal.com/guidepromo.tmpl > >_______________________________________________ > >Gamedevlists-general mailing list > >Gam...@li... > >https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > >Archives: > >http://sourceforge.net/mailarchive/forum.php?forum_id=557 > > > > > > > > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Gamedevlists-general mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=557 > |
|
From: Antoine C. <a.c...@gm...> - 2004-10-13 11:44:15
|
On Wed, 13 Oct 2004 10:23:16 +0100, Richard Fabian <ra...@gm...> wrote: > > so really it just boils down to what you're comfortable with, with te > caveat that maybe you should be comfortable with using cast to lvalue. However, afaik using cast as lvalues isn't standard. It's deprecated now in gcc. |
|
From: Richard F. <ra...@gm...> - 2004-10-14 09:06:21
|
We can carry on forever on this e.g. "you should be using static_cast" On Wed, 13 Oct 2004 13:42:53 +0200, Antoine Chavasse <a.c...@gm...> wrote: > On Wed, 13 Oct 2004 10:23:16 +0100, Richard Fabian <ra...@gm...> wrote: > > > > > so really it just boils down to what you're comfortable with, with te > > caveat that maybe you should be comfortable with using cast to lvalue. > > However, afaik using cast as lvalues isn't standard. > It's deprecated now in gcc. > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Gamedevlists-general mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=557 > |
|
From: Ola O. <ola...@gm...> - 2004-10-14 09:31:16
|
Well, its quite a difference between using different coding styles that are standard conformant and writing code that may not compile on the next platform you want to target... So, thanks for pointing that out, Antoine. And really, you should be using reinterpret_cast ;) cheers .ola ----- Original Message ----- From: "Richard Fabian" <ra...@gm...> To: <gam...@li...> Sent: Thursday, October 14, 2004 7:06 PM Subject: Re: [GD-General] Offset a void pointer > We can carry on forever on this e.g. "you should be using static_cast" > > On Wed, 13 Oct 2004 13:42:53 +0200, Antoine Chavasse > <a.c...@gm...> wrote: > > On Wed, 13 Oct 2004 10:23:16 +0100, Richard Fabian <ra...@gm...> wrote: > > > > > > > > so really it just boils down to what you're comfortable with, with te > > > caveat that maybe you should be comfortable with using cast to lvalue. > > > > However, afaik using cast as lvalues isn't standard. > > It's deprecated now in gcc. > > |
|
From: Richard F. <ra...@gm...> - 2004-10-14 14:11:09
|
if you are referring to this: http://gcc.gnu.org/gcc-3.4/changes.html from the section starting: "The cast-as-lvalue extension has been removed for C++ and deprecated for C and Objective-C. In particular, code like this: " then that is just that GCC has caught up with MS compilers in dissallowing the implicit lvalue return of standard C style casts Still appears to be perfectly legal to cast to an explicit lvalue type... Please correct me if i am wrong on this... At least in my head it certainly seems to make no sense to take out casting to a modifiable type... Regarding Ola Olsson: static_cast is a little bit safer, as the types Cavey Gerard was referring to were reasonably compatible. AFAIK reinterpret_cast is used to allow you to do more "dodgy" casting, e.g. between a function pointer and a float, something which static_cast does not do... Again, please correct me if i am wrong. On Wed, 13 Oct 2004 13:42:53 +0200, Antoine Chavasse <a.c...@gm...> wrote: > On Wed, 13 Oct 2004 10:23:16 +0100, Richard Fabian <ra...@gm...> wrote: > > > > > so really it just boils down to what you're comfortable with, with te > > caveat that maybe you should be comfortable with using cast to lvalue. > > However, afaik using cast as lvalues isn't standard. > It's deprecated now in gcc. > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Gamedevlists-general mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=557 > |
|
From: Antoine C. <a.c...@gm...> - 2004-10-14 15:28:59
|
On Thu, 14 Oct 2004 15:11:04 +0100, Richard Fabian <ra...@gm...> wrote: > if you are referring to this: > > http://gcc.gnu.org/gcc-3.4/changes.html > from the section starting: > "The cast-as-lvalue extension has been removed for C++ and deprecated > for C and Objective-C. In particular, code like this: " > > then that is just that GCC has caught up with MS compilers in > dissallowing the implicit lvalue return of standard C style casts I don't think so. I think it's more that they're catching up with iso c++ 99 standard, as most compilers, including MS ones, do. In fact, that change happened at the same time they rewrote their c++ parser from scratch to attain better standard conformance. They refer is as "cast-to-lvalue *extension*", which imo imply that it's not part of the standard. > > Still appears to be perfectly legal to cast to an explicit lvalue type... Not if you consider that "cast-as-lvalue", as they put it, might mean "using a cast expression as if it was a lvalue". I don't see any exception being made here depending on what you're casting to. > > Please correct me if i am wrong on this... At least in my head it > certainly seems to make no sense to take out casting to a modifiable > type... I don't know, it doesn't surprise me they forbid it. It seems to me that about the only thing it could be used for is to specify the size of data pointed by a void pointer, as you shown before. What would it mean in other cases ? What would it do ? > > Regarding Ola Olsson: static_cast is a little bit safer, as the types > Cavey Gerard was referring to were reasonably compatible. AFAIK > reinterpret_cast is used to allow you to do more "dodgy" casting, e.g. > between a function pointer and a float, something which static_cast > does not do... reinterpret_cast is indeed the most permissive C++ cast, but iirc it's usage is not guaranteed to be portable (for reasons like endianess) |
|
From: Staffan L. <sta...@gb...> - 2004-10-14 17:57:49
|
> I don't think so. I think it's more that they're catching up with iso > c++ 99 standard, as most compilers, including MS ones, do. In fact, > that change happened at the same time they rewrote their c++ parser > from scratch to attain better standard conformance. > They refer is as "cast-to-lvalue *extension*", which imo imply that > it's not part of the standard. None of the constructs in this thread have been using the "cast-as-lvalue extension" of GCC. The extension is transparently converting an rvalue to an lvalue. That's why the example, char *p; ((int *) p)++; compiles. The cast (int*) should result in an rvalue, hence applying the post inc. operator shouldn't be legal. There is no rule that explicitly prohibits casting an lvalue of one type to an lvalue of another type. But I agree that (char*&)BufferPtr+=stride looks unintuitive. Staffan |
|
From: Peter L. <pe...@to...> - 2004-10-14 16:52:26
|
the other problem was that pointer arithmetic can't be done on a void* since the size of the object it points to isn't defined. One of his casts let the compiler treat it as a char* pointer - the other form did the arithmetic on a void* and then cast it to a char*. > -----Original Message----- > From: gam...@li... > [mailto:gam...@li...]On Behalf Of > Richard Fabian > Sent: Thursday, October 14, 2004 7:11 AM > To: gam...@li... > Subject: SPAM-LOW: Re: [GD-General] Offset a void pointer > > > if you are referring to this: > > http://gcc.gnu.org/gcc-3.4/changes.html > from the section starting: > "The cast-as-lvalue extension has been removed for C++ and deprecated > for C and Objective-C. In particular, code like this: " > > then that is just that GCC has caught up with MS compilers in > dissallowing the implicit lvalue return of standard C style casts > > Still appears to be perfectly legal to cast to an explicit lvalue type... > > Please correct me if i am wrong on this... At least in my head it > certainly seems to make no sense to take out casting to a modifiable > type... > > Regarding Ola Olsson: static_cast is a little bit safer, as the types > Cavey Gerard was referring to were reasonably compatible. AFAIK > reinterpret_cast is used to allow you to do more "dodgy" casting, e.g. > between a function pointer and a float, something which static_cast > does not do... > Again, please correct me if i am wrong. > > > On Wed, 13 Oct 2004 13:42:53 +0200, Antoine Chavasse > <a.c...@gm...> wrote: > > On Wed, 13 Oct 2004 10:23:16 +0100, Richard Fabian > <ra...@gm...> wrote: > > > > > > > > so really it just boils down to what you're comfortable with, with te > > > caveat that maybe you should be comfortable with using cast to lvalue. > > > > However, afaik using cast as lvalues isn't standard. > > It's deprecated now in gcc. > > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > > Use IT products in your business? Tell us what you think of > them. Give us > > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to > find out more > > http://productguide.itmanagersjournal.com/guidepromo.tmpl > > _______________________________________________ > > Gamedevlists-general mailing list > > Gam...@li... > > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > > Archives: > > http://sourceforge.net/mailarchive/forum.php?forum_id=557 > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to > find out more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Gamedevlists-general mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=557 > |
|
From: Antoine C. <a.c...@gm...> - 2004-10-14 17:24:14
|
On Thu, 14 Oct 2004 15:11:04 +0100, Richard Fabian <ra...@gm...> wrote: > if you are referring to this: > > http://gcc.gnu.org/gcc-3.4/changes.html > from the section starting: > "The cast-as-lvalue extension has been removed for C++ and deprecated > for C and Objective-C. In particular, code like this: " > > then that is just that GCC has caught up with MS compilers in > dissallowing the implicit lvalue return of standard C style casts > > Still appears to be perfectly legal to cast to an explicit lvalue type... > > Please correct me if i am wrong on this... At least in my head it > certainly seems to make no sense to take out casting to a modifiable > type... > Alright, my apologies, for I misunderstood what they meant. The comments in gcc release notes were only refering to gcc extension of cast-as-lvalue as in the additional stuff they allowed there, not as cast-as-lvalue as a whole. I tried to compile this with gcc 3.4.0: void *ptr; (char*&)ptr += 5; and indeed, it worked. Trying to compile void *ptr; (char)ptr += 5; gave the following error message: "error: ISO C++ forbids cast to non-reference type used as lvalue" Which confirm that the standard allows using cast as a reference, and only them, as lvalues, so you were right. I'll be banging my head on some nearby wall. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X