Visual Studio 2010

[kolofsson]

Hey, I just installed the new Visual Studio 2010 Professional from the MSDN Academic Alliance (it's free for students!).

First thing I did was opening the SFML2 snapshot solution. At first, it converted itself to VS2010 format. Then i compiled the static and the dynamic build with 15 successful builds and only one fail (VOIP sample). I successfully ran some samples and all seem to work. That's good news I guess, because it means it should not be a hard time for Laurent to fully support VS2010 in next release.

And one off-topic question: when is the SFML2 release+documentation expected to see broad daylight? :wink:

[panithadrum]

I can't download it because it isn't updated at my MSDNAA software list. Looks like I'll have to wait a little more. I'm downloading the express version (I think there is no difference anyway...).

So good it build successfully. Why did the VOIP sample build failed?

About the SFML2 documentation... I think it is already OK (if you build it with doxygen :-))

[Laurent]

And one off-topic question: when is the SFML2 release+documentation expected to see broad daylight?

SFML 2 release... still too soon to tell

The documentation is almost complete (I just have to complete drawables classes before it's ready), so I think I'll upload it in the next few days. The tutorials will require a lot more work though.

[Nexus]

I can't download it because it isn't updated at my MSDNAA software list. Looks like I'll have to wait a little more.

You could also have a look at Microsoft DreamSpark.

[Ashenwraith]

And one off-topic question: when is the SFML2 release+documentation expected to see broad daylight?

SFML 2 release... still too soon to tell

The documentation is almost complete (I just have to complete drawables classes before it's ready), so I think I'll upload it in the next few days. The tutorials will require a lot more work though.

Hey, I got a quick Q about drawables.

Is it possible to implement it so you can put all drawables in an array so you can loop through them with draw?

[Nexus]

Is it possible to implement it so you can put all drawables in an array so you can loop through them with draw?

You can do that already now. Store pointers.

Concerning automatic deallocation, you might consider Boost.PointerContainer.

[Ashenwraith]

Is it possible to implement it so you can put all drawables in an array so you can loop through them with draw?

You can do that already now. Store pointers.

Concerning automatic deallocation, you might consider Boost.PointerContainer.

What's the difference between an array and a pointer in C++?

It seems like an array is a pointer, but don't all pointers/arrays have to be of the same type and drawables is abstract?

Without an external class to bundle, would that not be possible?

[Nexus]

What's the difference between an array and a pointer in C++?

I mean, you should store pointers in arrays. Or better use containers:

Code: [Select]

std::vector<sf::Drawable*> myDrawables;
And the best is to have a class that cleans up automatically and that is exception-safe. Boost's pointer containers are also handier to use (e.g. regarding dereferencing):

Code: [Select]

boost::ptr_vector<sf::Drawable> myDrawables;
// fill container
myWindow.Draw(myDrawables[0]);

It seems like an array is a pointer

No, it is not. An array is a collection of multiple objects of the same type. A pointer is an indirection to another object or to null.

but don't all pointers/arrays have to be of the same type and drawables is abstract?

The static type is the same, not the dynamic type. Inheritance allows abstraction: You can have pointers to base objects although they're actually pointing to an instance of the derived class. The same applies to references.

Code: [Select]

sf::Sprite sprite; // sf::Sprite inherits sf::Drawable
sf::Drawable* drawablePointer = &sprite;
sf::Drawable& drawableReference = sprite;

[Ashenwraith]

I know what pointers and arrays are conceptually, but isn't an array essentially an indexed list of pointers?

And also, aren't arrays much faster than vectors, especially for linear iterations?

[Nexus]

but isn't an array essentially an indexed list of pointers?

No. Actually, arrays are independent of pointers. The reason why those two concepts are often confused is that there exists an implicit conversion from an array to a pointer to the first element of the array. That's why you can write

Code: [Select]

T array[size];
T* ptr = array;

And also, aren't arrays much faster than vectors, especially for linear iterations?

Static, stack-based arrays are faster, but they're not flexible because the size must be known at compile time and cannot change. For static arrays, the class std::tr1::array is very useful, as it doesn't have the problems of C arrays like out-of-range accesses, non-copyability or the lack of a generic interface.

In practice, you often need dynamically allocated arrays and other data structures. One way is to use new[] and delete[], but in many cases, there are better alternatives. Here, the STL containers (std::vector is one of them) come into play. Some of their advantages are:

• Automatic memory management. You needn't call delete[] nor worry about memory leaks. Your code becomes exception-safe.
• A lot of useful functions (e.g. to erase/insert elements or to get the size). When you use new[], you have to store the number of elements separately and you need tedious loops when inserting an element.
• Uniform interface inside the STL. When you decide to switch from a linear vector to a doubly linked list, just typedef the container type and change one identifier at one place in the code. Imagine the equivalent refactoring using new[] and delete[].
• Support for debugging. The most STL implementations perform runtime checks in debug mode, this means errors like invalid indices are immediately detected.
• Zero abstraction overhead. Thanks to this C++ philosophy, the STL containers are not slower than manually using new[] and delete[] for the very most cases. Why should they be? They use the same functionality in a generic, encapsulated design (classes and templates). The STL may even be faster, since you can 1. choose the best-fitting data structure, 2. provide specific allocator strategies, 3. make use of optimizations like pre-allocations at std::vector.

[kolofsson]

The tutorials will require a lot more work though.

Oh yes, I meant the tutorials, not the documentation. :oops:

Regarding the array/pointer argument: that's what creeps me about C++. With script languages like PHP things are much more intuitive. And when you talk about pointers in C++ it is really hard to grasp. In my programs, I would like to keep away from managing the memory by myself.

[Ashenwraith]

but isn't an array essentially an indexed list of pointers?

No. Actually, arrays are independent of pointers. The reason why those two concepts are often confused is that there exists an implicit conversion from an array to a pointer to the first element of the array. That's why you can write

Code: [Select]

T array[size];
T* ptr = array;

And also, aren't arrays much faster than vectors, especially for linear iterations?

Static, stack-based arrays are faster, but they're not flexible because the size must be known at compile time and cannot change. For static arrays, the class std::tr1::array is very useful, as it doesn't have the problems of C arrays like out-of-range accesses, non-copyability or the lack of a generic interface.

In practice, you often need dynamically allocated arrays and other data structures. One way is to use new[] and delete[], but in many cases, there are better alternatives. Here, the STL containers (std::vector is one of them) come into play. Some of their advantages are:

• Automatic memory management. You needn't call delete[] nor worry about memory leaks. Your code becomes exception-safe.
• A lot of useful functions (e.g. to erase/insert elements or to get the size). When you use new[], you have to store the number of elements separately and you need tedious loops when inserting an element.
• Uniform interface inside the STL. When you decide to switch from a linear vector to a doubly linked list, just typedef the container type and change one identifier at one place in the code. Imagine the equivalent refactoring using new[] and delete[].
• Support for debugging. The most STL implementations perform runtime checks in debug mode, this means errors like invalid indices are immediately detected.
• Zero abstraction overhead. Thanks to this C++ philosophy, the STL containers are not slower than manually using new[] and delete[] for the very most cases. Why should they be? They use the same functionality in a generic, encapsulated design (classes and templates). The STL may even be faster, since you can 1. choose the best-fitting data structure, 2. provide specific allocator strategies, 3. make use of optimizations like pre-allocations at std::vector.

Well, I figured since I'm using C++ I might as well try to get as low as I can for optimization so I'm currently using arrays and pointers that are manually deleted.

When I have my first tool done that handles thousands of images, I'll convert a copy to std::vector and compare the result of the speeds.

[Nexus]

Regarding the array/pointer argument: that's what creeps me about C++. With script languages like PHP things are much more intuitive. And when you talk about pointers in C++ it is really hard to grasp.

Yes, C++ is indeed a complex language. But if you once understand the core features, you have with C++ a very flexible, powerful toolbox at hand.

In my programs, I would like to keep away from managing the memory by myself.

That's what I want, too, and that's what I am currently doing. Using RAII, you don't have to manage the memory manually for the very most cases. Working directly with new and delete all the time is error-prone anyway, you should try to avoid it if possible. Classes like containers or smart-pointers help you managing the memory automatically. Unfortunately, many people think that C++ forces the programmer to free allocated memory explicitly like C. This is a spread mistake.

Well, I figured since I'm using C++ I might as well try to get as low as I can for optimization so I'm currently using arrays and pointers that are manually deleted.

This the wrong attidude. You are programming in C++, not C. And since abstraction costs almost nothing on modern compilers, why abandon it? There are points like safety, intuitive and easy usage, extensibility which are much more important in the long term.

Your approach is also called premature optimization. You choose the tedious, error-prone way because you assume the alternative is slower and this difference in speed is of important matter. You're not even sure! And usually, that assumption is wrong. Most often, other algorithms (rendering, collision detection, physics, ...) require the crucial part of time. Trying to optimize by guessing problems doesn't really lead to a faster, but mostly to a less stable application and to bad code. You should really not choose that way because you've once heard arrays would be faster than vectors. In my upper post, I showed you situations where the opposite applies.

When I have my first tool done that handles thousands of images, I'll convert a copy to std::vector and compare the result of the speeds.

Okay. Ensure that you test both approaches under the same conditions, otherwise the test is useless. Switch to release mode, enable full optimizations and deactivate any runtime-checks. For example, MSVC++ works with checked iterators by default.

[dabo]

Hey, I just installed the new Visual Studio 2010 Professional from the MSDN Academic Alliance (it's free for students!).

That's unfair, I still only have Beta 1.