| BZNotify | bzflag: macsforme commented on pull request #238 "SDL2: Only create the window once" by blast007 (https://git.io/JeAvu): On macOS, these work:... | 04:43 |
|---|---|---|
| Flash | the question was asked, and deserves broader explanation. Isn't construction by initialization faster by construction by assignment | 05:41 |
| Flash | Foo foo(bar); vs Foo foo = bar; | 05:42 |
| Flash | historically, the second case (assignment) actually default constructed 'foo' then did assignment of 'bar' to 'foo' | 05:42 |
| Flash | however, in modern C++, we have move semantics, which makes the difference negligible in most cases | 05:43 |
| 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:44 |
| 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:45 |
| Flash | Obviously, for more detail, google "c++ move semantics" and you will almost certainly find a good explanation with examples. | 05:46 |
| 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 | 05:48 |
| macsforme | Flash: initializing a variable to a value has no additional cost over leaving it uninitialized? | 06:58 |
| 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:12 |
| Flash | cyclomatic complexity considers many factors, including the state of named variables | 07:15 |
| macsforme | especially since I could see myself writing something similar | 07:15 |
| Flash | if a variable is uninitialized, then you have to determine at every case whether it has a value before being used | 07:16 |
| 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:16 |
| DTRemenak | uniform initialization is the best initialization. Spell it Foo foo{ bar }. | 07:23 |
| macsforme | just not when using auto :-) | 07:24 |
| Flash | https://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/ | 07:25 |
| DTRemenak | works with auto too, but I like having the type stated explicitly exactly once. makes intentions clear. | 07:25 |
| Flash | and DTRemenak ... brace initialization doesn't work (necessarily) if Foo has constructors that take arguments | 07:26 |
| DTRemenak | single-argument constructors should generally be explicit | 07:26 |
| Flash | agreed | 07:26 |
| 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 | 07:27 |
| BZNotify | bzflag: atupone synchronized pull request #237 "subs gluProject with glm::project" (https://git.io/JeN0g) | 08:59 |
| BZNotify | master @ bzflag: atupone pushed 1 commit (https://git.io/JeAkU): | 09:04 |
| BZNotify | master @ bzflag: atupone d1aace: subs gluProject with glm::project (https://git.io/JeAkT) | 09:04 |
| BZNotify | bzflag: atupone commented on pull request #237 "subs gluProject with glm::project" (https://git.io/JeAkq): Merged | 09:04 |
| BZNotify | bzflag: atupone closed pull request #237 | 09:04 |
| BZNotify | bzflag: atupone commented on pull request #236 "C++14" by jwmelto (https://git.io/JeAGg): As for the new commit about gluProject moved to glm:project, I hope... | 16:00 |
| *** sam <sam!foobar@poulet.zoy.org> has quit IRC (Ping timeout: 250 seconds) | 19:07 | |
| *** sam <sam!foobar@poulet.zoy.org> has joined #bzflag | 19:13 | |
| *** sam is now known as Guest10009 | 19:14 | |
| *** Guest10009 <Guest10009!foobar@poulet.zoy.org> has quit IRC (Ping timeout: 258 seconds) | 19:20 | |
| *** sam_ <sam_!foobar@poulet.zoy.org> has joined #bzflag | 19:20 | |
| 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:00 |
| blast007 | allejo: I'll try here. | 23:02 |
| spldart | trying linux now | 23:24 |
| spldart | make flollowed through. trying play now | 23:25 |
| spldart | ./ plays fine too. | 23:27 |
| blast007 | allejo: it worked here. What version of glm do you have? | 23:35 |
| blast007 | ("here" being Debian Buster, with glm 0.9.9.3) | 23:35 |
| spldart | crap.. I dunno how to tell what pull ytou have from git. It's either commit 64920cc822952a28779557371e5e78fffd24c4e0 | 23:35 |
| spldart | or e928ab7695bdc1258be48f48b1243bb15662b05e But check ok | 23:35 |
| allejo | libglm-dev 0.9.7.2-1 | 23:36 |
| allejo | `git show HEAD` | 23:36 |
| spldart | Look at all that code! | 23:38 |
| *** Guest66163 is now known as Foo_man_choo | 23:40 | |
| spldart | Holy crap! gitk is awesome!! | 23:48 |
| spldart | Can't figure out how to check... 0.9.9.6 :/ | 23:55 |
| blast007 | are you using the glm from Debian? | 23:58 |
| blast007 | if so: apt show libglm-dev | 23:58 |
| allejo | i'm on ubuntu 16.04 | 23:59 |
| blast007 | 16.04 has glm 0.9.7.2 | 23:59 |
Generated by irclog2html.py 2.17.3.dev0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!