- [leisure] balz 3d - 1 Update
- std::hexfloat - 8 Updates
| fir <profesor.fir@gmail.com>: May 18 03:21PM -0700 i once wrote some basic app for simple phisics made from 2d balls, heres the vide from that app https://www.youtube.com/watch?v=qEi6pXU8hLk recently i wrote 3d version of it too tired to make video but heres the screenshot http://minddetonator.htw.pl/balz3d.png and here is the exe /win32 http://minddetonator.htw.pl/balz3d.zip (not malware, if youre paranoid try uplowading it to online scanner like virustotal or maybe run in wirtual machine, should also work in wine/linux) use space to fire some balls to hit objects on scene use tilda key to unhide/hide cursor and reize window hold shift when moving mouse to strafe camera move this doesnt maybe look to much soectacular, but i only worked on it 1-2 days (basen on 2d version, also might have small bugs becouse i dont bopther to repair them) hovever it is potentially sorta fun , i mean its potentially fun to discuss it (even in various aspects, like 1) hov improve look 2) discss physics behind that 3) i could turn it to dll library allowing some do defining its ovn constructs and test it 4) etc so maybe some opinions/hints what to do with that? |
| Richard Damon <Richard@Damon-Family.org>: May 17 09:45PM -0400 On 5/17/19 6:54 PM, Daniel wrote: > why this is not allowed? > Thanks, > Daniel The unary minus isn't part of the hex floating point constant, just as it isn't in the value -1 (there are no negative integer literals) That doesn't mean that inserters/extractors can't use that format for negative numbers. |
| blt_8oWHg36_@32fkxnh90wz2bllefiqy.co.uk: May 18 10:14AM On Fri, 17 May 2019 15:54:44 -0700 (PDT) >My understanding is that (2) is illegal, that a unary minus operator cannot >appear before a hex floating point representation, but can someone explain >why this is not allowed? I didn't even know hexfloat existed. It seems a spectacularly useless manipulator. What on earth is the point of it? |
| Bonita Montero <Bonita.Montero@gmail.com>: May 18 01:15PM +0200 > I didn't even know hexfloat existed. It seems a spectacularly > useless manipulator. What on earth is the point of it? You can serialize floating-point-values loss-free in ACII-files with it. |
| Bo Persson <bo@bo-persson.se>: May 18 02:27PM +0200 On 2019-05-18 at 00:54, Daniel wrote: > My understanding is that (2) is illegal, that a unary minus operator cannot > appear before a hex floating point representation, but can someone explain > why this is not allowed? The hexfloat is a bit odd, as it really only works for output... For numeric input, the spec for the num_get facet specifically says that the only characters allowed are "0123456789abcdefxABCDEFX+-". https://en.cppreference.com/w/cpp/locale/num_get/get (see Stage 2) So ss >> y would stop at the 'p' anyway. The committee didn't want to break old code reading "1.0p" as one double and one char, like in ss >> y >> ch. Bo Persson |
| blt_nyybrw6e@93ho0557z0x.edu: May 18 03:56PM On Sat, 18 May 2019 13:15:13 +0200 >> useless manipulator. What on earth is the point of it? >You can serialize floating-point-values loss-free in ACII-files >with it. You can already do that with standard hex: float f = 1.234; cout << hex << *((long *)&f) << endl; |
| Bonita Montero <Bonita.Montero@gmail.com>: May 18 06:03PM +0200 > You can already do that with standard hex: > float f = 1.234; > cout << hex << *((long *)&f) << endl; That's might not run on every platform and isn't guaranteed to be portable. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: May 18 06:12PM On Sat, 2019-05-18, Bonita Montero wrote: >> cout << hex << *((long *)&f) << endl; > That's might not run on every platform and isn't > guaranteed to be portable. "Not guaranteed to be portable" is too mild: you might as well say "might accidentally work". Unless there are special language rules around long/float conversion which I'm unaware of. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: May 18 09:33PM +0100 > "Not guaranteed to be portable" is too mild: you might as well say > "might accidentally work". Unless there are special language rules > around long/float conversion which I'm unaware of. It's not technically a conversion, it's a re-interpretation of the bits in the object. Not that that's any more portable! Not only are there language issues that make the /code/ non-portable (for example, on my system long is twice the size of float) but there are also endian issues that make the output non-portable. -- Ben. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment