| 04:43.08 | BZNotify | bzflag: 03macsforme commented on pull request #238 "SDL2: Only create the window once" by 03blast007 (06https://git.io/JeAvu): On macOS, these work:... |
| 05:41.54 | Flash | the question was asked, and deserves broader explanation. Isn't construction by initialization faster by construction by assignment |
| 05:42.11 | Flash | Foo foo(bar); vs Foo foo = bar; |
| 05:42.45 | Flash | historically, the second case (assignment) actually default constructed 'foo' then did assignment of 'bar' to 'foo' |
| 05:43.19 | Flash | however, in modern C++, we have move semantics, which makes the difference negligible in most cases |
| 05:44.36 | Flash | What are move semantics, you may ask? It's when the right hand side of the assignment is basically swapped with the left hand side, consuming it. |
| 05:45.47 | Flash | All the standard types (strings, vectors, maps, etc.) have move constructors so that the cost of the "copy" is swapping a few pointers |
| 05:46.27 | Flash | Obviously, for more detail, google "c++ move semantics" and you will almost certainly find a good explanation with examples. |
| 05:48.12 | Flash | what it means in practical terms is that we can confidently write code like "auto foo = bar"; (yes, I replaced the explicit type with 'auto'; a 2-for-1 example) instead of diligently constructing by initialization |
| 06:58.14 | macsforme | Flash: initializing a variable to a value has no additional cost over leaving it uninitialized? |
| 07:12.56 | macsforme | obviously it's not an optimization issue in this case (for a function called rarely), just trying to understand why you consider uninitialized variables "complex," if the needed values cannot be directly assigned during initialization |
| 07:15.06 | Flash | cyclomatic complexity considers many factors, including the state of named variables |
| 07:15.10 | macsforme | especially since I could see myself writing something similar |
| 07:16.04 | Flash | if a variable is uninitialized, then you have to determine at every case whether it has a value before being used |
| 07:16.31 | Flash | in this particular case, it's trivial, but as a best practice, variables should be declared at first use, and given initial values |
| 07:23.19 | DTRemenak | uniform initialization is the best initialization. Spell it Foo foo{ bar }. |
| 07:24.33 | macsforme | just not when using auto :-) |
| 07:25.11 | Flash | https://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/ |
| 07:25.43 | DTRemenak | works with auto too, but I like having the type stated explicitly exactly once. makes intentions clear. |
| 07:26.12 | Flash | and DTRemenak ... brace initialization doesn't work (necessarily) if Foo has constructors that take arguments |
| 07:26.29 | DTRemenak | single-argument constructors should generally be explicit |
| 07:26.34 | Flash | agreed |
| 07:27.08 | DTRemenak | ambiguity between list initializers and multi-argument constructors is rare, but that is a case where you might want to use a different style of initialization |
| 08:59.39 | BZNotify | bzflag: 03atupone 11synchronized pull request #237 "subs gluProject with glm::project" (06https://git.io/JeN0g) |
| 09:04.00 | BZNotify | 02master @ bzflag: 03atupone pushed 1 commit (06https://git.io/JeAkU): |
| 09:04.01 | BZNotify | 02master @ bzflag: 03atupone 14d1aace: subs gluProject with glm::project (06https://git.io/JeAkT) |
| 09:04.40 | BZNotify | bzflag: 03atupone commented on pull request #237 "subs gluProject with glm::project" (06https://git.io/JeAkq): Merged |
| 09:04.41 | BZNotify | bzflag: 03atupone 04closed pull request #237 |
| 16:00.24 | BZNotify | bzflag: 03atupone commented on pull request #236 "C++14" by 03jwmelto (06https://git.io/JeAGg): As for the new commit about gluProject moved to glm:project, I hope... |
| 19:13.46 | *** join/#bzflag sam (foobar@poulet.zoy.org) |
| 19:20.54 | *** join/#bzflag sam_ (foobar@poulet.zoy.org) |
| 23:00.30 | allejo | is master failing for anyone else? this is the error I'm getting, MeshTransform.cxx:389:7: error: no match for âoperator=â (operand types are âglm::vec3 {aka glm::tvec3<float, (glm::precision)0u>}â and âglm::tmat4x4<float, (glm::precision)0u>::col_type {aka glm::tvec4<float, (glm::precision)0u>}â) |
| 23:02.11 | blast007 | allejo: I'll try here. |
| 23:24.58 | spldart | trying linux now |
| 23:25.49 | spldart | make flollowed through. trying play now |
| 23:27.22 | spldart | ./ plays fine too. |
| 23:35.03 | blast007 | allejo: it worked here. What version of glm do you have? |
| 23:35.42 | blast007 | ("here" being Debian Buster, with glm 0.9.9.3) |
| 23:35.45 | spldart | crap.. I dunno how to tell what pull ytou have from git. It's either commit 64920cc822952a28779557371e5e78fffd24c4e0 |
| 23:35.46 | spldart | or e928ab7695bdc1258be48f48b1243bb15662b05e But check ok |
| 23:36.00 | allejo | libglm-dev 0.9.7.2-1 |
| 23:36.34 | allejo | `git show HEAD` |
| 23:38.08 | spldart | Look at all that code! |
| 23:48.05 | spldart | Holy crap! gitk is awesome!! |
| 23:55.45 | spldart | Can't figure out how to check... 0.9.9.6 :/ |
| 23:58.01 | blast007 | are you using the glm from Debian? |
| 23:58.13 | blast007 | if so: apt show libglm-dev |
| 23:59.14 | allejo | i'm on ubuntu 16.04 |
| 23:59.52 | blast007 | 16.04 has glm 0.9.7.2 |