Getting close!
I added the "Other Fleets Here" GUI element. I also implemented the functions to populate the list.
As soon as I implement the functionality for split/merge and cargo, we will be ready for a developer test game!
Sunday, July 26, 2009
Friday, July 24, 2009
Concepts Are Dead in C++0x
Long live Concepts in C++1x!
What are concepts? And what is C++0x?
C++0x is (in addition to being the worst name ever for anything) the next standards update to C++. It endeavors to add more to C++, not because C++ needs to be more complicated (which it already is, and which it will become more so), but to try and add some badly missing features to make C++ competitive with higher level languages.
Bjarne has a FAQ page.
Let's fisk the individual features he comments on:
What are concepts? And what is C++0x?
C++0x is (in addition to being the worst name ever for anything) the next standards update to C++. It endeavors to add more to C++, not because C++ needs to be more complicated (which it already is, and which it will become more so), but to try and add some badly missing features to make C++ competitive with higher level languages.
Bjarne has a FAQ page.
Let's fisk the individual features he comments on:
- "auto" keyword - good, D had this since version 1
- for(auto x : container) - good, wordier than D version 1
- fix for template<nested<>> - good to see this fixed, sorry for compiler and tool writers who need to make it work
- default and delete - meh
- enum class - good (if oddly named), D version 1
- constexpr - good, D "pure" functions (maybe not until version 2) are more powerful
- decltype - meh, I believe D has better introspection with typeof(?), etc.
- initializer lists - not sure how much of a win this is, adds a lot of complexity. Built-in array types seems a better (simpler) solution
- preventing narrowing - meh
- delegating constructors - good, D version 1
- in class member init - yeah!, D version 1
- inherited constructors - meh
- compile time assert - D version 1 (plus contracts are way better)
- long long - ugh, why not standardize on int64_t?
- nullptr - ugly name, D version 1 has null
- suffix return type - "[] mul(T x, U y) -> decltype(x*y)" ahhh!!!!! that looks like ML or something else that Cthulhu would write
- template alias - meh
- variadic templates - much needed, although more complicated templates makes my head want to explode
- more initialization syntax - cause more is better
- rvalue references - wow, that is some ugly syntax. All hail swap!
- union fixes - "s.~string();" nuff said
- POD - meh
- raw strings - meh
- user defined literals - wow, I mean wow. Why? 'constexpr complex<double> operator "i"(long double d)' Why? Please, why?
- attributes - seems good
- lambda - yea! D version 1
- local types as template arguments - never ran into this bug, good to see it fixed
- C99 - meh
- extended integer - why wasn't <stdint.h> enough?
- extern templates - this is how some early template implementations worked, maintenance headache
- std::array - D version 1
- unique_ptr - nice
- concepts - this would be nice. Much closer to what Java allows for its (much weaker) version of templates.
- More. More. More. It's all complexity-plus-plus. More complicated compiler, more bugs, more complicated IDE, more to learn, more to remember, more to code. Maybe a little less to code, sometimes. Ugh.
- A lot of this is no longer looking like C. What is some embedded guy who misses this update going to think when he sees this code? He'll have no idea what is going on.
- How long before I can actually use this stuff? Sure, g++ will have it quickly... MSVC will probably take 3-5 years after the standard (because they will keep trying to push their incompatible version). What about dmc? Or weird embedded compilers whose vendors have gone out of business? Oh, they'll never have this... which means, I shouldn't be using it if I need to be cross compatible. Which means I can't use it for the next 10 years.
- All this to get what D had in version 1. D version 2 will be done in the next year, and usable from day 1.
Tuesday, July 07, 2009
New Stars Status
Wow, a big change, not very fun, I was putting it off for a long time...
Notice the Long Range Scout is now named #1274... I have converted the ship design and fleet ids to follow the map given in my Sourceforge post (planet ids were the same before and after).
This revealed a bug that Cygwin Tcl 8.4 does not honor wide ints as 64 bits. It compiles, but apparently just gives you 32 bits... ugh. Then I had to switch everything over to -mno-cygwin, rebuild everything, and use the ActiveState Tcl (which is 8.5).
Since the new object id code makes use of rand, all the planets changed (which means I have to redo all the player orders). So, I took the opportunity to sort in the additional names John sent months ago. We now support ~2.5k planets with names. We will probably need an automated scheme for larger universes (which would probably be populated entirely by AI's, who aren't going to care about planet names).
I changed the fleet name label to left align. This is a little ugly for the shorter planet names, but it is much better for the longer fleet names. I also fixed a bug where fleet path highlighting would remain when you switch to a planet view.
Notice the Long Range Scout is now named #1274... I have converted the ship design and fleet ids to follow the map given in my Sourceforge post (planet ids were the same before and after).
This revealed a bug that Cygwin Tcl 8.4 does not honor wide ints as 64 bits. It compiles, but apparently just gives you 32 bits... ugh. Then I had to switch everything over to -mno-cygwin, rebuild everything, and use the ActiveState Tcl (which is 8.5).
Since the new object id code makes use of rand, all the planets changed (which means I have to redo all the player orders). So, I took the opportunity to sort in the additional names John sent months ago. We now support ~2.5k planets with names. We will probably need an automated scheme for larger universes (which would probably be populated entirely by AI's, who aren't going to care about planet names).
I changed the fleet name label to left align. This is a little ugly for the shorter planet names, but it is much better for the longer fleet names. I also fixed a bug where fleet path highlighting would remain when you switch to a planet view.
Subscribe to:
Posts (Atom)