Messages

1

General discussions / Re: Is sf::GlResource not missing an explicit copy constructor?

« on: August 04, 2014, 09:21:08 am »

Yes, I misunderstood that.

2

General discussions / Re: Is sf::GlResource not missing an explicit copy constructor?

« on: August 03, 2014, 11:03:33 pm »

What's the point of arguing? Since it can be called, it must be defined, so that it does what it's supposed to do.

If you call the default copy ctor of a derived class the default copy ctor of the parent will be called too. That is the point.

3

Graphics / Re: sf::RenderTexture problem

« on: August 03, 2014, 10:05:31 pm »

Okay, something is wrong:
http://oi60.tinypic.com/2hyyo01.jpg
http://oi58.tinypic.com/28tevj7.jpg
http://oi58.tinypic.com/2s1a9si.jpg

Did you link to the new libraries?

4

General discussions / Re: Is sf::GlResource not missing an explicit copy constructor?

« on: August 03, 2014, 09:24:42 pm »

Mind showing us your test then?

I showed you mine, and the result speaks for itself.

Oh, sorry. I did not test with an explicit copy ctor of a derived class. You are right. This calls the parent's ctor if not defined explicitly.

But still, an implicit copy ctor on both classes causes the counter not to increase. I would recommend adding an explicit copy ctor to sf::GlResource nevertheless. Just for safety.

5

General discussions / Re: Is sf::GlResource not missing an explicit copy constructor?

« on: August 03, 2014, 09:13:19 pm »

What you are forgetting is that any (even the implicitly) declared base class copy constructor has to be explicitly called by the derived class copy constructor, else the base class constructor will be called instead. GlResource does have an implicitly declared and defined copy constructor, but since none of the derived classes explicitly call it, its normal constructor is called instead, thus incrementing the reference count as expected every time a GlResource is copy constructed.

Here is a demonstration of this.

I tested this and I disagree.

6

General discussions / Is sf::GlResource not missing an explicit copy constructor?

« on: August 03, 2014, 07:46:01 pm »

GlResource::GlResource()
{
    ...
        // Increment the resources counter
        count++;
    ...
}
 

As far as I can tell, every created instance of GlResource increases the count. I am just wondering, why there is no copy constructor defined that would increase it, too?

The default copy constructor just copies all attributes (which is none).

Therefore, if I am not fully mistaking, it is possible to cause a call to ensureContext() after globalCleanup(), because the count is smaller than the actual number of GlResource instances.

Please tell me, if I am missing something.


EDIT: I just tested, whether a copying of a derived class really calls the parent's copy constructor. And it does. I also tested it without explicit declaration of a copy constructor and the default one is called. Thus, my thoughts are correct. But maybe SFML handles it another way.

7

General / Re: Using SFML in own dll

« on: June 15, 2013, 03:26:53 pm »

Ok it is working now, thanks. But there are some warning messages though:

1. VC is complaining about not finding debug information (.pdb), but that is irrelevant
2. The compiler says, that sf::RenderWindow is no DLL-Interface/port and is used as base class for Window
Code for that (german):

warning C4275: class 'sf::RenderWindow' ist keine DLL-Schnittstelle und wurde als Basisklasse für die DLL-Schnittstelle class 'gse::Window' verwendet

Like said, it is working, but I don't like the second warning

Forgot to mention that I linked statically

8

General / Re: Using SFML in own dll

« on: June 15, 2013, 08:51:19 am »

Yes ok. But how can I solve my window problem from above?

9

General / Re: Using SFML in own dll

« on: June 14, 2013, 11:08:35 pm »

Is there no other way to achieve that without implementing all sfml code into my dll?

10

General / Re: Using SFML in own dll

« on: June 14, 2013, 09:35:35 pm »

Maybe short instruction to do that in VC++, please?

Oups, should have been an edit...

11

General / Re: Using SFML in own dll

« on: June 14, 2013, 08:42:58 pm »

I think he wants to create dll that when included provides SFML without need to include/link it explicitly.

Why is it pointless?

floats are usually 4 bytes, pointers(so references too) are 4 or 8(so more or equal) + there is cost of dereferencing and so on..

1. Yes, that's what I want to have! Tell me how to do this.
2. Ok understood, thanks

12

General / Re: Using SFML in own dll

« on: June 14, 2013, 08:31:48 pm »

Make sure the SFML headers are in the path of include directories. Everything is explained in the official tutorial, please read it carefully.

So I do have to include SFML to my executable... I wanted to include my lib only...

And returning a const-reference to float is pointless. Just return a copy.

Why is it pointless?

13

General / Re: Using SFML in own dll

« on: June 14, 2013, 08:13:27 pm »

Well I've some problems with including the header:
Example:

(Of course there are include guards, namespace etc. but I left them to keep it short)

window.h

#include <SFML/Graphics.hpp>

class Window : public sf::RenderWindow{
public:
   const float& update();
...
};

 

and in my executable

#include <GSE/Window.h>

...
Window window;
...

 

And I'm getting errors, that it cannot find SFML/Graphics.hpp. He found the error in the Window.h. Looks like my compiler is trying to recompile my library.

How do I do it right?

VC++ is my IDE

14

General / Re: Issue with Joystick axes

« on: June 13, 2013, 08:22:25 pm »

I think you are mixing up joystick with controller. Controller is the thing for xbox/ps/etc with 2 sticks and joystick is for the computer with one stick. Maybe this is your problem and I think that controllers aren't supported by SFML...

15

General / Re: Using SFML in own dll

« on: June 13, 2013, 07:28:48 pm »

Actually you replied what I wanted to know. It was just that short because I've written those messages with my mobile. Thanks for help