Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Visual Studio 2010  (Read 6681 times)

0 Members and 1 Guest are viewing this topic.

kolofsson

  • Full Member
  • ***
  • Posts: 100
    • View Profile
Visual Studio 2010
« on: April 13, 2010, 06:54:17 pm »
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

  • Sr. Member
  • ****
  • Posts: 304
    • View Profile
    • Skyrpex@Github
    • Email
Visual Studio 2010
« Reply #1 on: April 13, 2010, 07:22:29 pm »
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

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Visual Studio 2010
« Reply #2 on: April 13, 2010, 08:05:12 pm »
Quote
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.
Laurent Gomila - SFML developer

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Visual Studio 2010
« Reply #3 on: April 13, 2010, 08:11:19 pm »
Quote from: "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.
You could also have a look at Microsoft DreamSpark. ;)
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Ashenwraith

  • Sr. Member
  • ****
  • Posts: 270
    • View Profile
Visual Studio 2010
« Reply #4 on: April 13, 2010, 08:14:10 pm »
Quote from: "Laurent"
Quote
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

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Visual Studio 2010
« Reply #5 on: April 13, 2010, 08:15:10 pm »
Quote from: "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.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Ashenwraith

  • Sr. Member
  • ****
  • Posts: 270
    • View Profile
Visual Studio 2010
« Reply #6 on: April 13, 2010, 08:20:16 pm »
Quote from: "Nexus"
Quote from: "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

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Visual Studio 2010
« Reply #7 on: April 13, 2010, 08:33:10 pm »
Quote from: "Ashenwraith"
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]);


Quote from: "Ashenwraith"
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.

Quote from: "Ashenwraith"
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;
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Ashenwraith

  • Sr. Member
  • ****
  • Posts: 270
    • View Profile
Visual Studio 2010
« Reply #8 on: April 13, 2010, 08:58:01 pm »
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

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Visual Studio 2010
« Reply #9 on: April 13, 2010, 11:02:00 pm »
Quote from: "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;

Quote from: "Ashenwraith"
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.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

kolofsson

  • Full Member
  • ***
  • Posts: 100
    • View Profile
Visual Studio 2010
« Reply #10 on: April 14, 2010, 10:44:48 am »
Quote from: "Laurent"
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

  • Sr. Member
  • ****
  • Posts: 270
    • View Profile
Visual Studio 2010
« Reply #11 on: April 14, 2010, 04:24:37 pm »
Quote from: "Nexus"
Quote from: "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;

Quote from: "Ashenwraith"
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

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Visual Studio 2010
« Reply #12 on: April 14, 2010, 08:56:21 pm »
Quote from: "kolofsson"
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.

Quote from: "kolofsson"
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.

Quote from: "Ashenwraith"
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.

Quote from: "Ashenwraith"
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.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

dabo

  • Sr. Member
  • ****
  • Posts: 260
    • View Profile
    • http://www.dabostudios.net
Re: Visual Studio 2010
« Reply #13 on: April 18, 2010, 12:46:44 am »
Quote from: "kolofsson"
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. :D