Messages

31

General discussions / Design and documentation

« on: December 31, 2009, 03:12:50 pm »

I forgot what this technique is called, ...

It is called pimpl, handle-body or compiler firewall idiom.

No mutables, no const_cast, and no visible implementation details to the user

And a lot of additional possibility for failure, like there is one in your Code. You need to implement your own copy-constructor and operator=.

I would suggest to use this idiom with care and not only because you can avoid const_cast or mutable.

Dravere

32

General discussions / Design and documentation

« on: December 31, 2009, 02:48:43 pm »

How often do you change the view? I don't think that a copy of around 100 Bytes would do much damage. And if so, you could perhaps split the view up a bit. Is the matrix really necessary to be in the view the user uses? Couldn't the window use some type of ViewContainer which has an additional matrix. That would make 64 Bytes less to copy

As an abstract:

Code: [Select]


class View
{
public:
  // ... the known interface ...

private:
  sf::Vector2f myCenter;
  sf::Vector2f myHalfSize;
  FloatRect    myRect;
// remove this:  Matrix3 myMatrix;
// If I'm right we don't need this anymore either: bool myNeedUpdate;
// I think even the friend RenderWindow can be removed ...
};

// ...

class RenderWindow
{
private:
  class ViewHolder
  {
  public:
    //...
    void SetView(View const& view)
    {
       myView = view;
       myNeedUpdate = true;
    }
    //...
  private:
    View myView;
    Matrix3 myMatrix;
    bool myNeedUpdate;
  };

public:
  // ...

  void SetView(View const& view)
  {
    m_viewHolder.SetView(view);
  }


private:
  ViewHolder m_viewHolder;
};

I hope you can understand what I mean

Dravere

33

General discussions / Design and documentation

« on: December 31, 2009, 01:40:09 am »

The problem is: It is undefined behavior.

I'm not sure about the scope of this rule, but if it applies to any const variable then const_cast becomes pointless, doesn't it?

No it doesn't. Some examples:

Code: [Select]


struct Point
{
    float x;
    float y;
};

int main()
{
    const Point constantPoint = { 0.0f, 0.0f };
    const_cast<Point&>(constantPoint).x = 1.0f; // undefined behavior

    Point myPoint = { 0.0f, 0.0f };
    Point const& myPointNowConstant = myPoint;

    const_cast<Point&>(myPointNowConstant).x = 1.0f; // absoluty legal and defined.

    // If a bady interface is there or an old C one with no const,
    // the following is also correct:
    Point* thisIsATransport = const_cast<Point*>(&constantPoint);
    // ... there will be no modification through thisIsATransport
    Point const* pointerToConstantPoint = thisIsATransport;

    return 0;
}


// Or for exmpale this one is also legal and often used:
class MyClass
{
public:
    AnObject const& operator [](std::size_t index) const
    {
        // whatever ...
    }

    AnObject& operator [](std::size_t index)
    {
        return
            const_cast<AnObject&>(
                (*static_cast<MyClass const*>(this))[index]);
    }
};

Dravere

34

General discussions / Design and documentation

« on: December 31, 2009, 01:08:11 am »

Making members mutable is a little cleaner, but it appears in the public headers. Plus, a lot of members would be mutable, even those that are not just internal details of the class.
const_casts, on the other hand, are uglier but stay hidden in the implementation, and I prefer that :)

The problem is: It is undefined behavior.

ISO IEC 14882:2003 7.1.5.1 The cv-qualifiers Paragraph 4

Except that any class member declared mutable (7.1.1) can be modified, any attempt to modify a const object during its lifetime (3.8) results in undefined behavior.

Drave

35

Feature requests / Enable/Disable nagle algorithm

« on: October 17, 2009, 04:10:09 pm »

What would you need to enable/disable it for?

Enhance responsiveness. At least this is one of the common reason, why people disable the nagle algorithm.

Especially in a real time multiplayer game it can be usefull to disable the nagle algorithm, so the actions are sent immediatly over the net and there occurs no or less lag.

36

Graphics / sf::String uses UTF-16 BE or LE?

« on: December 02, 2008, 03:07:38 pm »

Thank you for the information.

What is the timetable on version 1.4? I just saw in the documentation that there will be also a very helpful unicode class.

37

Graphics / sf::String uses UTF-16 BE or LE?

« on: December 01, 2008, 01:00:44 am »

Hello,

The question is in the title. What does sf::String use for UTF-16 Strings, the Big Endian or the Little Endian version? Also what about the sf::Event::TextEvent::Unicode attribute?

Thx for your help.

Dravere

P.S: Just started a few days ago with SFML. As far I pretty much like your library, good work!