- neoGFX Sample Application - Chess [PROGRESS UPDATE - Basic Move Validation] - 1 Update
- "GotW #97: Assertions (Difficulty: 4/10)" by Herb Sutter - 4 Updates
- Users needed - 1 Update
- atomic<>-costs - 4 Updates
| Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk>: Jan 08 10:12PM Hi! neoGFX Sample Application - Chess [PROGRESS UPDATE - Basic Move Validation] : https://www.youtube.com/watch?v=tVm9sf7eBLs Basic move validation just implemented; validation of following moves still todo: * en passant * castling * check / checkmate * promotion To support these more complex moves I will introduce reverse indexing (storing the coordinates of each piece in an array separate to the board representation). Message ends. /Flibble -- π |
| Richard Damon <Richard@Damon-Family.org>: Jan 07 06:26PM -0500 On 1/7/21 4:11 PM, Scott Lurndal wrote: > I've seen them. Anytime there's a side effect in the assert, the behavior > will change when -DNDEBUG is specified. These can be very obscure and > difficult to find. It is especially easy if you have a function call that you use as part of the condition, that has side effects that you don't think about. |
| Juha Nieminen <nospam@thanks.invalid>: Jan 08 08:30AM > mistyped anything, and that if I change something in the future there > are less chances I screw it up. The asserts also document the needed > preconditions for next lines. One could also argue that unit tests do the same thing as asserts, and are better in this regard. |
| Ian Collins <ian-news@hotmail.com>: Jan 08 11:06PM +1300 On 08/01/2021 21:30, Juha Nieminen wrote: >> preconditions for next lines. > One could also argue that unit tests do the same thing as asserts, > and are better in this regard. Much better! -- Ian. |
| Vir Campestris <vir.campestris@invalid.invalid>: Jan 08 10:02PM On 06/01/2021 14:51, Alf P. Steinbach wrote: > system. Which can greatly influence the choice of leaving fast > assertions enabled or not. But e.g. for the latter, it seems to me > better that the system crashes than that it produces incorrect bills. Our systems aren't safety critical. We have asserts in place, which result in a crash dump being sent back for us to look at. They don't happen often; we caught all the obvious bugs in testing. But they do happen, and we can use the dumps, and the logs we collect, to make sure they don't happen again. Or at worst have some clue as to what checks to add to the next release. Andy |
| Brian Wood <woodbrian77@gmail.com>: Jan 08 09:13AM -0800 On Wednesday, July 25, 2018 at 12:33:19 AM UTC-5, Brian Wood wrote: > reward for providing a successful reference. More > info here: http://webEbenezer.net/about.html > . In this change I stopped using unique_ptr and the size of this program decreased over 1%. https://github.com/Ebenezer-group/onwards/commit/c08c0fce367dc01462b5a16d7799b6ecff5f3393 I'm not saying stop using unique_ptr, but in this case I think it was a good move. Brian Ebenezer Enterprises https://webEbenezer.net. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 08 09:04AM +0100 > Its an odd way to design things. You know, all threads might > not startup at the same time... ready, start and count, ect... ... There's no false sharing. |
| Juha Nieminen <nospam@thanks.invalid>: Jan 08 08:32AM > atomicValue needs to be completely isolated. Padded up to a cache line > and aligned on a boundary. Is there a standard way of doing that? |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 08 10:28AM +0100 >> atomicValue needs to be completely isolated. Padded up to a cache line >> and aligned on a boundary. > Is there a standard way of doing that? It's not necessary here. But if you need it you can do it that way: #include <iostream> #include <atomic> #include <thread> #include <cstdint> using namespace std; struct alignas(hardware_constructive_interference_size) { atomic<uint64_t> valaue; } a; int main() { cout << sizeof ::a << endl; bool fits = ((uintptr_t)&::a & 64 - 1) == 0; cout << (fits ? "fits" : "doesn't fit") << endl; } |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 08 10:48AM +0100 Better this way. > bool fits = ((uintptr_t)&::a & 64 - 1) == 0; bool fits = !(alignof(decltype(::a)) % 64); |
| 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