- Can extern "C" functions throw exceptions - 5 Updates
- How to get mantissa of long double? - 11 Updates
- "C++20 Coroutines" by Martin Bond - 1 Update
- rational numbers - 1 Update
- Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? - 1 Update
- Tricky ... - 1 Update
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Oct 06 01:12PM -0700 > linkage of the typedef determines the calling convention, while the > language linkage of the function itself determines the name > mangling. Can you illustrate how that would be done? Since the language linkage of a function is part of its type, it sounds like trying to do such a thing would inevitably lead to undefined behavior. |
| "daniel...@gmail.com" <danielaparker@gmail.com>: Oct 06 01:36PM -0700 On Saturday, September 11, 2021 at 11:00:42 AM UTC-4, Alf P. Steinbach wrote: > And these are the guys creating a Windows calculator > that by default evaluates 2+3*4 as (2+3)*4. In Standard mode, but not in Scientific or Programmer mode :-) |
| Branimir Maksimovic <branimir.maksimovic@icloud.com>: Oct 06 08:42PM >> And these are the guys creating a Windows calculator >> that by default evaluates 2+3*4 as (2+3)*4. > In Standard mode, but not in Scientific or Programmer mode :-) --main = print $ calculate "3 * 2 + 5 / 2" calculate :: String -> String calculate str = case (eval operatorRegister . words) str of Just r -> printf "%.2f" (fromRational r::Double) Nothing -> "Nothing" eval :: Register -> [String] -> Maybe Rational eval [] _ = Nothing -- No operator found. eval _ [] = Nothing -- If a operator don't have anything to operate on. eval _ [number] = let a :: Maybe Double = readMaybe number in case a of Just a -> Just (toRational a) Nothing -> Nothing eval ((operator, function):rest) unparsed = case span (/=operator) unparsed of (_, []) -> eval rest unparsed (beforeOperator, afterOperator) -> function <$> (eval operatorRegister beforeOperator) <*> (eval operatorRegister $ drop 1 afterOperator) -- 7-77-777 Evil Sinner! to weak you should be meek, and you should brainfuck stronger https://github.com/rofl0r/chaos-pp |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Oct 06 04:12PM -0700 > function > <$> (eval operatorRegister beforeOperator) > <*> (eval operatorRegister $ drop 1 afterOperator) I don't know what language that is, and you haven't bothered to tell us. (No, I'm not asking, just saying that whatever point your post might have is defeated by not knowing what language you're using.) Again, you've posted something that isn't relevant either to the subject of this newsgroup (the C++ language) or to the thread (which is about extern "C" functions throwing exceptions, with a passing reference to the Windows calculator program). This kind of thing is a problem. I can solve it for myself by configuring my newsreader to stop showing me your posts. You can solve it for everyone by not making off-topic posts. (The fact that you post obscure things without any explanation is just icing on the unpleasant cake.) Please don't just post whatever you think is interesting. Consider whether it's appropriate. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips void Void(void) { Void(); } /* The recursive call of the void */ |
| Branimir Maksimovic <branimir.maksimovic@icloud.com>: Oct 06 11:22PM > I don't know what language that is, and you haven't bothered to tell us. > (No, I'm not asking, just saying that whatever point your post might > have is defeated by not knowing what language you're using.) Petty, one of the favorite Hacker languages :P (Haskell) , besides /forth and ASSE/mbler :P > of this newsgroup (the C++ language) or to the thread (which is about > extern "C" functions throwing exceptions, with a passing reference to > the Windows calculator program). Who cares, this is not *mderated* group, you just embarrased yourself not recognizing simple calculator in Haskell :P > Consider whether it's appropriate. It is talk was about calculator :p -- 7-77-777 Evil Sinner! to weak you should be meek, and you should brainfuck stronger https://github.com/rofl0r/chaos-pp |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 06 07:58AM +0200 Am 05.10.2021 um 20:21 schrieb Bart: >>> $ >> That's pure software - your CPU doesn't natively support 128 bit FP. > Does it matter? Yes, It's rare that you need 128 bit FP and it's even more rare that the speed doesn't matter. |
| David Brown <david.brown@hesbynett.no>: Oct 06 08:11AM +0200 On 06/10/2021 07:58, Bonita Montero wrote: >> Does it matter? > Yes, It's rare that you need 128 bit FP and it's even more rare that > the speed doesn't matter. Until a couple of days ago, you didn't think 128-bit floating point existed. Now you think you know how it is used and what is important to users? There was a time when /all/ floating point, at least on "normal" computers, was in software. Yet people used it - including 64-bit doubles which were much slower than 32-bit float. Then floating point co-processors became common, and made floating point somewhat faster (though still slow). And people used them. There are a great many processors that still don't have hardware floating point, and people use software floats if they need floating point. You do so because getting the correct answer is more important than getting a fast answer. If you need the greater precision or range of quad precision floating point, then you use that. If it is slow, you accept that - or you pay the price for faster hardware. There does not seem to be much call for quad precision - not enough for many cpu manufacturers to spend the significant die space needed to implement it in hardware. But there is enough call for it to be implemented in software on many tools (gcc and clang for x86 have it as __float128, and I'd be slightly surprised if MS doesn't have some support through a similar extension), it is specified in a number of cpu architecture documents for future implementation, and there are many library implementations available. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 06 10:25AM +0200 Am 06.10.2021 um 08:11 schrieb David Brown: > Until a couple of days ago, you didn't think 128-bit floating point > existed. ... Where did I say that ? I only said that ARM 128 bit FP is just an ABI-issue. |
| Bart <bc@freeuk.com>: Oct 06 12:12PM +0100 On 06/10/2021 06:58, Bonita Montero wrote: >> Does it matter? > Yes, It's rare that you need 128 bit FP and it's even more rare that > the speed doesn't matter. You keep avoiding my point Suppose you HAVE 80-bit or 128-FP, and need to extract the mantissa, how would you do it? It's like someone asking how to work out the 5th root of a number, and you give a method for the square root. Then when pressed, you say that is is rare to need a 5th root! |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 06 02:48PM +0200 Am 06.10.2021 um 13:12 schrieb Bart: > You keep avoiding my point > Suppose you HAVE 80-bit or 128-FP, and need to extract the mantissa, how > would you do it? As the 1 high-bit is alwas included in the 64 bit mantissa of a 80 bit FP-value that's much easier. In contrast to smaller FP-values where the one bit implicity except from denormal values or values with the maximum exponent. union { long double value; struct { uint64_t mantissa; uint16_t exponent : 15, sign : 1; }; } Just store your value into value and extract the mantissa from mantissa. |
| scott@slp53.sl.home (Scott Lurndal): Oct 06 02:25PM >Until a couple of days ago, you didn't think 128-bit floating point >existed. Now you think you know how it is used and what is important to >users? It seems the most popular new floating point format today is 16-bit floating point (bfloat16 in ARM) - important in machine learning applications. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 06 04:53PM +0200 Am 06.10.2021 um 16:25 schrieb Scott Lurndal: > It seems the most popular new floating point format today is 16-bit > floating point (bfloat16 in ARM) - important in machine learning > applications. I think that's popular only for KI-puposes. Even for computer graphics that's not sufficient. |
| red floyd <no.spam.here@its.invalid>: Oct 06 09:44AM -0700 On 10/6/2021 5:48 AM, Bonita Montero wrote: > }; > } > Just store your value into value and extract the mantissa from mantissa. Does anyone know if type punning through a union is still undefined behavior? Also, I believe bitfield allocation is implementation defined. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 06 06:52PM +0200 Am 06.10.2021 um 18:44 schrieb red floyd: >> Just store your value into value and extract the mantissa from mantissa. > Does anyone know if type punning through a union is still undefined > behavior? It's a de-facto standard for all compilers because such constructs are needed very often. Otherwise it's specified that you can alias anything as a array of chars and an array of chars as anything - I think that's specified because this is nice to have for serialization-purposes. So you can cast a type to a char * and then further to the destination type to get the same effect. This definitely prevents any optimization tricks of the compiler which would sabotage this. > Also, I believe bitfield allocation is implementation defined. The way than I did is at least portable among x86-compilers. On platforms where you have a differnt byte-order this won't work, but these platforms don't have a 80 bit FP type anyway. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 06 07:02PM +0200 > The way than I did is at least portable among x86-compilers. > On platforms where you have a differnt byte-order this won't > work, but these platforms don't have a 80 bit FP type anyway. To be more precise here: there are some differences in how x86 compilers handle bitfields, but there are also commonalities. And the binary layout of the above structure is definitely the same for all x86-compilers. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 06 01:57PM -0700 On 10/6/2021 4:12 AM, Bart wrote: > It's like someone asking how to work out the 5th root of a number, and > you give a method for the square root. Then when pressed, you say that > is is rare to need a 5th root! This does seem to be a pattern for her. Humm... |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Oct 06 01:19PM -0700 > while (state) state = (State)state(&d); > C++ has trouble writing the recursive type, so you need a cast, but > its a safe cast. In C++, needing a cast can be avoided by wrapping the function pointer in a class or struct, as for example: class State { typedef State (*Go)( data & ); Go go; public: State( Go g ) : go( g ) {} operator bool(){ return go; } State operator()( data &data ){ return go( data ); } }; void run_state_machine( State initial, data &data ){ State s = initial; while( s ) s = s( data ); } The example above is specific to a partcular type of "data" being acted on, but it's easy to generalize around that shortcoming by using templates. |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Oct 06 01:06PM -0700 >> "4/16 reduces to 1/4 and evaluates to 0.25" > I still think that designwise such a function does not belong in > that class. That depends on exactly what the function does. If the function depends on the object's internal representation or on invariants that are not publically available, then certainly defining the function as a member function is a more natural choice. |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Oct 06 01:01PM -0700 >>> platforms. >> You forgot to say "IMHO". > Redundant, surely. Whose opinion could it be, if not Juha 's? One of the reasons for including "IMO" or "IMHO" is to show that the speaker understands and appreciates the differences between fact, belief, and opinion. Also consider the puzzle related to the very logical island people who deliberately avoid learning their own eye color. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 06 12:22PM -0700 On 10/4/2021 10:13 PM, Bonita Montero wrote: >>> Lock-free is when you only have a fast path - and no slow path. >> Why not combine the two? Ahhh, the futex, or eventcount. > Then it's not lock-free anymore. However, it has lock-free fast-paths. That is a huge advantage! |
| 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