Commit Graph

  • c800ddb348 Better version that still has both functions, but asserts a warning when misused, or you can implement it if you need. master Zed A. Shaw 2025-02-09 21:37:57 -0500
  • c1f1eee58b Actually this works, so...yeah why don't they just do this? Zed A. Shaw 2025-02-09 21:32:49 -0500
  • 6f346f3357 Two possible ways to fix drawable to avoid the const problem, but not quite right. Zed A. Shaw 2025-02-09 21:30:54 -0500
  • 43e3fb8582 Original should be the name of the starting point for this experiment. Zed A. Shaw 2025-02-09 21:15:27 -0500
  • 9410d37d12 The fix is simple: Just don't have RenderTarget (which is literally named render TARGET) also be in charge of rendering things to itself. Zed A. Shaw 2025-02-09 21:13:52 -0500
  • 5f25383891 Added a small micro example of the problem with SFML's use of const on drawable virtual functions which shows the _real_ reason they did this is because of a poor design decision to make both Drawable and RenderTarget equally in charge of drawing the other. AKA the 'Deadly Embrace' design flaw. Zed A. Shaw 2025-02-09 20:31:58 -0500
  • b8395c6d9f Got a test case working that shows emplace_back and push_back do the same function calls in every instance except for one. Zed A. Shaw 2025-01-21 11:01:22 -0500
  • bba4b2463e Initial commit of a small project to keep a record of various things in C++ that confuses me, other people, or are just down right dumb and should be avoided. This will be where I link people who tell me something is fast or better. Zed A. Shaw 2025-01-21 06:46:18 -0500
  • 57b4dd6b61 Initial commit Zed A. Shaw 2025-01-21 12:01:56 +0100