Itches, Glitches & Anything Else...

[New Horizon]

Works fine after the full checkout. Thanks for the help guys. DR is looking and running really well. Fantastic work.

[greebo]

Cool. Glad it was nothing more serious. For the next release this kind of pain won't happen (promised) as I already have an idea for a simple upgrading system that's not too hard to implement.

 

@Orbweaver: could you edit this task into the todo-list in the programming forum? (Or am I able to do this myself, I don't know?)

 

I also got some news for the vector.h refactoring: I have added most of the operators to the Vector3 class (*, *=, +, +=, -, -=, /, /=, inner product) and already replaced all deprecated vector3_dot() function calls. I won't commit it yet, however, as I want to wait till DR 0.7.0 is released.

[ascottk]

I keep getting an error which crashes dr (0.7.0rc1):

lib/modulesystem/singletonmodule.h:95

assertion failure still referenced at shutdown

&

libs/moduleobservers.h:36

assertion failure: ModuleObservers::~ModuleObservers:

observers still attached

[greebo]

When does this error occur? Right at startup or at shutdown or sometime random?

[OrbWeaver]

I have added the version stamping to the list of tasks. Something you might consider doing is applying a "version" property to each node, rather than the file as a whole, which would mean that custom colour schemes etc. could be given a higher version allowing them to be merged in rather than overwritten.

 

I am surprised that ascottk is getting an assertion failure on a release build, all assertions should be compiled out in release builds.

[greebo]

I just accidentally committed the .cdtproject and .project files (I meant to tick them off but obviously forgot this). How can I revert such a change on the server? The files are made for my Windows environment, so you don't want to update now, I guess.

 

Do I have to revert the change to revision 83 and re-commit the files?

[OrbWeaver]

What are the diffs from the last version? It may be that there is no significant change.

[greebo]

I use a different binary parser and such. They won't fit for Linux environments, I'm afraid.

 

edit: Hm. Update to Revision works for my local copy, but it doesn't let me commit the reverted copies.

[OrbWeaver]

That's true, Windows needs the PE Binary parser or something.

 

I wouldn't worry about it, any time I check out afresh from SVN I have to set all the project settings anyway, no matter what gets committed in the .project and .cdtproject.

[greebo]

Ok, then.

 

I've changed a lot files btw, most of the deprecated vector3_yyyy functions are history now.

 

edit: Ah, found it, the changes are reverted now.

[OrbWeaver]

I'm glad you've started on this, those C functions were long overdue to be removed. I'm also fairly sure that the mystical "infinite loop with Windows inlining" bug was caused by some of these functions, which means we can be even more hopeful it won't manifest itself once this is done.

 

Just a couple of notes:

 

1. You don't need to specify members as inline if they are defined in the class declaration, since methods defined in this way are automatically considered inline. You may notice that this implicitly requires all templated methods to be declared inline, which is in my view a particularly ugly piece of language design (and one of several reasons why I personally dislike templates).

2. I don't think there is any point in defining operator* or operator/ in ways that are not mathematically defined, unless there is actually code which requires them. Is there any code which needs an elementwise multiplication or division of two vectors? I would be quite happy to have operator* overloaded as a dot product operation, however.

[greebo]

I'm glad you've started on this, those C functions were long overdue to be removed. I'm also fairly sure that the mystical "infinite loop with Windows inlining" bug was caused by some of these functions, which means we can be even more hopeful it won't manifest itself once this is done.

No problem, I could have been faster, but I took my time, because I didn't want to break anything. The Vector2 and Vector4 classes are to follow.

 

1. You don't need to specify members as inline if they are defined in the class declaration, since methods defined in this way are automatically considered inline. You may notice that this implicitly requires all templated methods to be declared inline, which is in my view a particularly ugly piece of language design (and one of several reasons why I personally dislike templates).

I don't understand this entirely. Do you mean that the inline keyword can be skipped here?

 

2. I don't think there is any point in defining operator* or operator/ in ways that are not mathematically defined, unless there is actually code which requires them. Is there any code which needs an elementwise multiplication or division of two vectors? I would be quite happy to have operator* overloaded as a dot product operation, however.

Unfortunately, there is code that requires the vectors to be multiplicated in this mathematically incorrect way. I would have gladly removed this, but I didn't want to stir too much dirt up here.

[OrbWeaver]

No problem, I could have been faster, but I took my time, because I didn't want to break anything. The Vector2 and Vector4 classes are to follow.

 

Excellent.

 

I don't understand this entirely. Do you mean that the inline keyword can be skipped here?

 

Yes. If you declare a class in a header file like this:

 

class MyClass {
public:
 void myMethod() {
 // do something here
 }
};

 

The myMethod() is implicitly declared inline because its body is present in the class declaration (rather than being defined separately in a .cpp file as MyClass::myMethod()).

 

Unfortunately, there is code that requires the vectors to be multiplicated in this mathematically incorrect way. I would have gladly removed this, but I didn't want to stir too much dirt up here.

 

Fair enough.

[greebo]

Yes. If you declare a class in a header file like this:

 

class MyClass {
public:
 void myMethod() {
 // do something here
 }
};

Do I get this right: as soon as I put the implementation of a member function into the class declaration it becomes an inline function, even without the keyword inline. Do templated functions need to be implemented in the header file or is it possible for them to be moved into the cpp file?

 

(I can imagine that these vector functions are "important" enough to have them inlined as they are used a lot and should be fast, so I probably wouldn't want to move them in a cpp file, but I just want to understand this right.)

 

I will remove the inline from the declaration keyword, then.

[OrbWeaver]

Do I get this right: as soon as I put the implementation of a member function into the class declaration it becomes an inline function, even without the keyword inline.

 

Correct. Although it is up to the compiler whether it actually inlines it or not (and you can override this behaviour with a GCC option), but the effect of putting the implementation in the class declaration is semantically identical to using the inline keyword.

 

Do templated functions need to be implemented in the header file or is it possible for them to be moved into the cpp file?

 

They have to be implemented in the header file, because the compiler needs to see the entire definition of the function in order to instantiate the template when it is used. Normally the compiler would only need to see the method's signature (the undefined method that you normally put in a header file) in order to generate a symbol which is linked by the linker, but it cannot do this for templates because depending on what template parameters you use, there may not be any matching instance of the template to link to.

[greebo]

Ok, thanks for explaining, highly appreciated!

 

I'm off to working on BasicVector2 now...

[OrbWeaver]

I wonder to what extent these vector classes even need to be templated. Have you ever seen a use of BasicVector that didn't use <float> as the parameter?

[greebo]

Unfortunately yes. I saw a BasicVector3 at least once, which was causing a compiler problem with accessing the member variables of the -Vector in the methods. I got around this by accessing the components via other.x() instead of static_cast(other.m_elements[0]).

 

This happened with the += operator, so I guess there is a vector addition with a double vector out there somewhere. I couldn't be arsed to go into detail and investigate if the double was necessary, so I changed the implementation.

 

edit: it's radiant/winding.h and libs/math/plane.h that use such a type.

[OrbWeaver]

There is a good argument for using doubles internally anyway, for precision reasons. Perhaps a good future task would be to convert everything to use double, and then de-template the BasicVector3 class into a single Vector3 which holds doubles internally.

[sparhawk]

The myMethod() is implicitly declared inline because its body is present in the class declaration (rather than being defined separately in a .cpp file as MyClass::myMethod()).

 

Is this standard? I always thought that you have to use the inline option to actually make it so.

[greebo]

There is a good argument for using doubles internally anyway, for precision reasons. Perhaps a good future task would be to convert everything to use double, and then de-template the BasicVector3 class into a single Vector3 which holds doubles internally.

Shouldn't this work by just changing the Vector3 definition to BasicVector3?

[OrbWeaver]

Is this standard? I always thought that you have to use the inline option to actually make it so.

 

Yes, it's standard. If this wasn't the case, you would get a linker error when you included the header file into multiple .cpp files and tried to link them together, because there would be a duplicate definition of the function. If a function is "inline", this signifies to the linker that all definitions are identical and it can just pick one.

 

Shouldn't this work by just changing the Vector3 definition to BasicVector3<double>?

 

Yes, but if everything uses the same kind of Vector (or can be converted to do so) we might as well scrap the template.

[greebo]

Yes, but if everything uses the same kind of Vector (or can be converted to do so) we might as well scrap the template.

Ok, I'll look into it. Is there a difference between double and float in terms of speed?

[OrbWeaver]

Ok, I'll look into it. Is there a difference between double and float in terms of speed?

 

Possibly, but probably not in practice. The details depend on your implementation, but for the most part the floating point operations will not be the bottleneck, and the avoidance of precision-based problems down the line should make up for any (minor/small/negligible/non-existent) differences in performance.

[greebo]

Ok, thought so. I don't know if there are any precision-critical applications in DarkRadiant.

 

Another thing: I found that the Vector2 class is only used by patch.cpp a few files. Should I split the generic/vector.h into parts (generic/vector2.h, etc.)?