Comments (8)
This is a great idea. I remember somewhere I saw a similar proposal, but it was a long time ago.
Also in the future, make changes to the memory for the 64-bit Celestia version to speed up its work, because now there is no difference between the two.
from celestia.
The auto keyword I don't like, it is hard to verify what datatype it has.
// auto int x; // valid C++98, error as of C++11
// auto x; // valid C, error in C++
In Stellarium are many of C++11 features, but it is sometimes hard to read the code.
So you can not see when viewing the code if its a int, float or double pointer, iterator or anything else.
And I see the gcc >= 4.8.1 has full C++11 see cxx-status but MSVC there are less info about it, but until 2015 it has no full C++11 support.
But it is ok for new features when it is readable in future when examining code.
from celestia.
auto
keyword is very useful for cases like
for (Foo<Bar>::const_iterator iter = foobars.begin(); iter< foobars.env(); iter++) {
Bar bar = *iter;
when we can have just for (auto bar : foobars)
or VeryLongTypename * t = new VeryLongTypename()
or foobar_t x = (foobar_t)expression
.
These cases are obvious. Of course one shouldn't use auto for cases like auto x = fn()
.
from celestia.
Ok, this is better for the iterators, I found this and equivalent in code:
for (Array::const_iterator iter = a->begin(); iter != a->end(); iter++)
here the iter++ is a performance issue, the post increment hold a copy the previous element.
See performance warnings with cppcheck:
Prefer prefix ++/-- operators for non-primitive types.
Better with ++iter
.
I changed this in render.cpp line 3972
for (vector<RenderListEntry>::iterator iter = renderList.begin();
iter != renderList.end(); ++iter)
{
if (iter->renderableType == RenderListEntry::RenderableBody && iter->body->getAtmosphere() != NULL)
to:
for (auto &iter : renderList)
or for (auto iter : renderList)
both got the compile error C2819: type 'RenderListEntry' does not have an overloaded member 'operator ->' at next line: if (iter->renderableType ...)
I use Visual Studio 2015
from celestia.
I found this: range based loops
Choose auto x when you want to work with copies. Choose auto &x when you want to work with original items and may modify them. Choose auto const &x when you want to work with original items and will not modify them.
It works when I change the -> operator to . : if (iter**.**renderableType == ...)
But this works:
vector<int> vec = {1, 2, 3, 4};
for (auto &x : vec)
{
x *= 10;
}
from celestia.
for ( range_declaration : range_expression ) loop_statement
is converted into
{
auto && __range = range_expression ;
for (auto __begin = begin_expr, __end = end_expr; __begin != __end; ++__begin) {
range_declaration = *__begin;
loop_statement
}
}
See https://en.cppreference.com/w/cpp/language/range-for
"Choose auto x when you want to work with copies." -- or when you work with primitive types.
from celestia.
Ok, so for non primitive types (the most usage) it is prefered the auto const &x
or auto &x
for performace.
To make a copy (ctor/dtor) for each object in the array can slow down when used big arrays or big objects
from celestia.
fixed in master
from celestia.
Related Issues (20)
- Pre-Windows 10 1903 versions of ICU HOT 2
- [Win32] Goto Object dialog ignores zeroes
- [Qt] Barycenters in star browser HOT 1
- CI: MacOS front-ends HOT 2
- setlocale is not thread safe, causing crash due to race HOT 2
- Classic star colors HOT 1
- Incorrect contexted string extracted from windows RC files
- Dubious test in shadermanager.cpp
- Could not read star database HOT 2
- Wasted data for ring systems
- Recent GTK changes cause build error HOT 6
- segfault when exiting celestia (qt5/qt6)
- std::binary_function is (deprecated in C++11) and (removed in C++17) HOT 1
- `ApplyShadow` result discarded during shader creation HOT 1
- Constellation lines beyond Solar System
- HUD translation contexts HOT 1
- compiling and running on Raspberry Pi 5 / Bookworm 64 bit HOT 7
- Orbits disappear after 4000 AD HOT 2
- Celestia on Raspberry Pi 5 Bookworm 64 bit Wayland: orbits, constellations/constellation borders, coordinate grids are not rendered HOT 15
- build error with fmt 11 HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from celestia.