• What are you working on? December 2011 Edition
    3,353 replies, posted
[QUOTE=Jookia;33933411]"ISO C++ forbids casting between pointer-to-function and pointer-to-object" I have all my compiler warnings turned on and let them all error. A union, or memcpy, is the only legal way in C++ to do what I want.[/QUOTE] reinterpret_cast lets you go from a data pointer to a function pointer, and it's perfectly defined and legal (unless you call it, but hey - using a union is just as undefined) Section 5.2.10 [i]Reinterpret cast[/i], subsection 6 of the C++ standard (working draft: [url]http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1905.pdf[/url]) [quote] A pointer to a function can be explicitly converted to a pointer to a function of a different type. The effect of calling a function through a pointer to a function type (8.3.5) that is not the same as the type used in the definition of the function is undefined. Except that converting an rvalue of type “pointer to T1” to the type “pointer to T2” (where T1 and T2 are function types) and back to its original type yields the original pointer value, the result of such a pointer conversion is unspecified. [Note: see also 4.10 for more details of pointer conversions. — end note ] [/quote] So using a reinterpret_cast is perfectly valid, bitch. [editline]29th December 2011[/editline] (just don't call the resulting function pointer) [editline]29th December 2011[/editline] Also if you want to get technical about it, your union bullshit is illegal anyway because it's an aliasing violation.
[QUOTE=swift and shift;33933473]reinterpret_cast lets you go from a data pointer to a function pointer, and it's perfectly defined and legal (unless you call it, but hey - using a union is just as undefined) Section 5.2.10 [i]Reinterpret cast[/i], subsection 6 of the C++ standard (working draft: [url]http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1905.pdf[/url]) So using a reinterpret_cast is perfectly valid, bitch. [editline]29th December 2011[/editline] (just don't call the resulting function pointer)[/QUOTE] I don't know if you actually read that, but that says you can convert function pointers to a function pointer that has a different type of function. Nothing about converting pointers to objects (void*) to function pointers. Furthermore, in the context of section 5.2.10, there's nothing about converting from a pointer to a function to a pointer to a object, thus you can't do it. [editline]29th December 2011[/editline] I'm not even arguing about the standard, try casting the result of dlsym with GCC's pedantic flag enabled.
[QUOTE=Jookia;33933530]I don't know if you actually read that, but that says you can convert function pointers to a function pointer that has a different type of function. Nothing about converting pointers to objects (void*) to function pointers. Furthermore, in the context of section 5.2.10, there's nothing about converting from a pointer to a function to a pointer to a object, thus you can't do it.[/QUOTE] sorry I interpreted that section wrong. Oh well, just scroll down to subsection 8 which says: [quote] Converting a pointer to a function into a pointer to an object type or vice versa is conditionally-supported. The meaning of such a conversion is implementation defined, except that if an implementation supports conversions in both directions, converting an rvalue of one type to the other type and back, possibly with different cv-qualification, shall yield the original pointer value. [/quote] so basically what you're trying to do is 'conditionally-supported' and 'implementation-defined', aka. it works on x86 but it may not work everywhere so the standard's not going to fully support it. that means you may as well do a nice little cast rather than that retarded union bullshit since it's undefined anyway and you're just trying to work around compiler warnings.
[QUOTE=swift and shift;33933578]sorry I interpreted that section wrong. Oh well, just scroll down to subsection 8 which says: so basically what you're trying to do is 'conditionally-supported' and 'implementation-defined', aka. it works on x86 but it may not work everywhere so the standard's not going to fully support it. that means you may as well do a nice little cast rather than that retarded union bullshit since it's undefined anyway and you're just trying to work around compiler warnings.[/QUOTE] Again, compiler warnings prevent me from casting. Unions don't. It's a workaround that works, and I'm pretty sure, correct me if I'm wrong, that it'll work on any architecture providing it follows the POSIX standard which specifies that void* is the same size as a function pointer. Not just x86. If it doesn't, then I'll just rewrite the code and not use a union. I don't get why you're so mad that I'm not casting. Furthermore, I showed you an example where I didn't need to wrap the POSIX API. [editline]29th December 2011[/editline] I'm also pretty sure I'm not breaking strict aliasing rules as I'm not aliasing symHack.
Time to put a stop to all this arguing. [vid]http://dl.dropbox.com/u/4081391/java%202011-12-28%2014-51-47-66.webmvp8.webm[/vid]
[QUOTE=Jookia;33933609] [editline]29th December 2011[/editline] I don't get why you're so mad that I'm not casting. Furthermore, I showed you an example where I didn't need to wrap the POSIX API.[/QUOTE] And he showed you an example where you do need to wrap it. Regardless of how well POSIX is defined, no C library is exception safe. This is a dumb argument. edit: that was strange, the text I quoted wasn't the text that ended up in my post o_O
[QUOTE=artanis;33933750]And he showed you an example where you do need to wrap it. Regardless of how well POSIX is defined, no C library is exception safe. This is a dumb argument.[/QUOTE] It's not specific to using C APIs in C++. If you have a C++ API that doesn't use RAII then you have the exact same problem. I'm just angry that he goes and says that 'don't use C libraries in C++', then shows shoddy C++ code (why would you not catch exceptions?) and acts as if it's the language and not programmer.
[url=http://anyhub.net/file/6cmK-release.7z][img]http://f.anyhub.net/4LfL[/img][/url] Now onto reflection and refraction
i'm breaking my promise not to post till WAYWO january edition b/c i really wanna chime in and say ... swift and shift, you're a moron that is all, carry on
[video=youtube;MEblcH6vDuY]http://www.youtube.com/watch?v=MEblcH6vDuY[/video]
[QUOTE=Ziks;33933881][url=http://anyhub.net/file/6cmK-release.7z][img]http://f.anyhub.net/4LfL[/img][/url] Now onto reflection and refraction[/QUOTE] [IMG]http://dl.dropbox.com/u/33076954/text..PNG[/IMG] Slight issues with the text
[QUOTE=Icedshot;33933971][IMG]http://dl.dropbox.com/u/33076954/text..PNG[/IMG] Slight issues with the text[/QUOTE] Oh hello again broken texture bug. It's because nVidia cards decide to start a new primitive before I finish giving it all my vertex data. I'll fix it in a minute.
[QUOTE=Icedshot;33933971][IMG]http://dl.dropbox.com/u/33076954/text..PNG[/IMG] Slight issues with the text[/QUOTE] Looks fine to me. You m̶aỳ ha͢v̨e ȁ̢͂̈ͧ ͗ͭ̋̓ͬ̊͜v̂ͦĩͤͯͥ̒ͨr̷̃ͯͣ͌̈́͐u͑͒ͬ̀ͩ͏s̛͂͗͐̏̇͒ Lͧ̋ͩ̑ͩͣ̀̄̇ͧͮ͑̾̑ͥ̾͂͏͇̟̻̫͓̱̞̖̻͔̤̘͎̭̦̠̀ͅÉ̢͌ͣ̄̅̓ͪ̂ͨ͟͝͏͈̤̠͇͉̞͎̥͎̯͇̞͡ͅA͙̺̳̳͎̪̤͎̅͐ͥ͗̽͂̐ͬͧͯ̉̾̌̅͗ͯ́͢͠V͚̜̣̺̝̭̣̥̱͎̫͎͚̙̦͑̐̐ͪͨ͋ͬ͗͞ͅE̥̹̞̣̫̳͙̘͖͓͓̭̔̎̍́ͭ̈́̾ͥ̀̃ͭͬ͆ͨ̊͗͗̀͢ͅ ̶̗̤͇͍̩̺̍̆͐ͬ̌ͦͭͫͧ͑́͟͠͠Ñ̋̈́̔̄̓͗͛͑ͤ̚̕҉͚̝͕͙͇͘O̷̟̪͚̟̘̹͕͛̒̈́ͦͯ̾͐͌ͯ͢W̶̨̛̙̪̺̗̔̃͌͐͑͒͒ͦ͢͜ i͠n͝ ͜W̡i͝n͟d̡ows̕'͢ fo̴n̸t ́ren͢d̷e͜r̕ing̡ system.
[QUOTE=mechanarchy;33932818]gui tips[/QUOTE] Hmm, ok, I'll look into something like that. Right now I'm trying to sort out the discrepancy in performance between the C# and C++ versions (C# one is faster).
[csharp]public override LightRay[] Interact( LightRay ray ) { Vector2d i = Line.Direction; Vector2d j = i.PerpendicularLeft; Vector2d newOrigin = ( ray.Origin - Line.Start ).ChangeBasis( i, j ); Vector2d newLeftField = ray.FieldRight.ChangeBasis( i, j ); Vector2d newRightField = ray.FieldLeft.ChangeBasis( i, j ); newOrigin.Y = -newOrigin.Y; newLeftField.Y = -newLeftField.Y; newRightField.Y = -newRightField.Y; return new LightRay[] { new LightRay( newOrigin.RevertBasis( i, j ) + Line.Start, newLeftField.RevertBasis( i, j ), newRightField.RevertBasis( i, j ), ray.ProjRight, ray.ProjLeft, LightRay.DefaultRange, LightRay.DefaultRange, ray ) }; }[/csharp] [img]http://anyhub.net/file/2N0x-reflection.png[/img] I love it when something works first try.
[QUOTE=NovembrDobby;33934072]Hmm, ok, I'll look into something like that. Right now I'm trying to sort out the discrepancy in performance between the C# and C++ versions (C# one is faster).[/QUOTE] If you want to paste code, I'll be glad to check it out.
Do you really want to sift through 18k lines of terrible code and work out where the bottlenecks are?
[QUOTE=NovembrDobby;33934209]Do you really want to sift through 18k lines of terrible code and work out where the bottlenecks are?[/QUOTE] You have no idea where the bottlenecks may be? Haven't you profiled your code?
[QUOTE=Jookia;33934219]You have no idea where the bottlenecks may be? Haven't you profiled your code?[/QUOTE] That's the point, it's what I'm doing now.
Oh, I thought this was a specific thing to do with the name GUI code, rather than the entire game.
[QUOTE=Jookia;33934248]Oh, I thought this was a specific thing to do with the name GUI code, rather than the entire game.[/QUOTE] You just can't stand the idea that a C# program outperforms a C++ one :D
[QUOTE=Darwin226;33934289]You just can't stand the idea that a C# program outperforms a C++ one :D[/QUOTE] All it means is that the c++ implementation is bad. C# cannot outperform the equivalent c++ application... :eng101:
[QUOTE=artanis;33934373]All it means is that the c++ implementation is bad.[/QUOTE] I'd be the first to agree with this. I am getting better at it though :3
[QUOTE=Ziks;33934132][img]http://anyhub.net/file/2N0x-reflection.png[/img][/QUOTE] May I ask you where the fuck the initial light comes from? :confuzzled:
[QUOTE=Darwin226;33934289]You just can't stand the idea that a C# program outperforms a C++ one :D[/QUOTE] It's one of the few things that makes me toss and turn at night and ruin relationships.
[QUOTE=Ziks;33933881][url=http://anyhub.net/file/6cmK-release.7z][img]http://f.anyhub.net/4LfL[/img][/url] Now onto reflection and refraction[/QUOTE] [img]http://i53.tinypic.com/xfuudx.png[/img] It's all bugged :(
[QUOTE=Darkwater124;33934444]May I ask you where the fuck the initial light comes from? :confuzzled:[/QUOTE] Yeah I was confused at first, but then I understood how it worked. [img]http://i.cubeupload.com/KKo6Rn.png[/img] [editline]28th December 2011[/editline] [QUOTE=DrLuke;33934481][img]http://i53.tinypic.com/xfuudx.png[/img] It's all bugged :([/QUOTE] Looks correct for me.. You only moved the light source to be at the bottom facing up. Look: [thumb]http://i.cubeupload.com/CnIExO.png[/thumb]
[QUOTE=Robbis_1;33934788] Looks correct for me.. You only moved the light source to be at the bottom facing up. Look: [thumb]http://i.cubeupload.com/CnIExO.png[/thumb][/QUOTE] If it was correct then why would there be light inside the squares?
[QUOTE=sim642;33934934]If it was correct then why would there be light inside the squares?[/QUOTE] When the squares are filled in everything is correct. For squares I only clip along the diagonal or closest face.
By any chance does anyone know if strings that you push to the Lua stack are copies of whatever you pass or not, and if you're passing a new char will Lua clean up that up for you? I get the feeling they're not copies.
Sorry, you need to Log In to post a reply to this thread.