Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Badestrand

Pages: [1]

Network / alternative to whatismyip.org

« on: December 13, 2008, 01:41:12 pm »

Hi,

to retrieve the public ip address, the website www.whatismyip.org is queried. Unfortunately, sometimes (seldomly, but it happens) this site is down, so it may be useful to check another site, too?
There is http://checkip.dyndns.org which sends back a strings like

Code: [Select]

<html><head><title>Current IP Check</title></head><body>Current IP Address: 84.58.110.116</body></html> which is a little more work to parse than the other one but I think it's worth.

edit: Oh, and one could work with the new Http-classes here.

Feature requests / Unicode-files and Normalization Forms

« on: November 30, 2008, 12:55:05 am »

Hi,

I was currently looking whether a new version of SFML has been released and saw the Unicode-class in the SVN-code. Very beautiful, the interface as well as the implementation

I'd like to ask: Are you planning to implement the loading and saving of unicode-files (and if so, please, use a BOM for UTF-8 ) and an (at least rudimentary) implementation of the unicode normalization forms? The file-thingy should be pretty straight-forward, while correct NFs might be really much work.
However, at least a very basic implementation (maybe just a few european combinations such as ä=>a¨) should be able to manage, if you need help, you know where you can find the community

General discussions / Libs + Dlls for Visual C++

« on: September 11, 2008, 04:33:50 am »

Hi!

Although I'm really(!) glad to have the pre-compiled libraries for VC05 & 08, there's one thing that's not 100% right in my oppinion.

First I'll explain what I know about delivering DLLs + Libs with the Visual Studio:
Generally, there are two ways to use other code through a library: Either you link it static which means you don't need a dll or dynamic which means you have a lib which contains some info about the dll (functions' entry points etc) and you'll need the dll.

When I link dynamically to some code, I need the classification between debug and non-debug since the DLL contains the debug-symbols when compiled in debug-mode.
When I'm linking statically, then the library has to be conform with two of my project-options: debug<->non-debug and crt-linked-static<->crt-linked-dynamic. This means that there have to be four versions of the static-lib.
This four-version-stuff sounds difficult but isn't, at least if you deliver only the libs to link against statically. Fortunately we can use the compiler-switches and the "#pragma comment" to include the libs automatically, might look like this (I can't remember the right macros right now, I will check it in a few hours):

Code: [Select]


#ifdef _MSVC
#    ifdef _DEBUG
#        ifdef BLA // crt-is-dynamic-linked; can't remember the name
#            pragma comment( lib, "sfml-system-d.lib" )
#        else
#            pragma comment( lib, "sfml-system-s-d.lib" )
#        endif
#    else
#        ifdef BLA // crt-is-dynamic-linked; can't remember the name
#            pragma comment( lib, "sfml-system.lib" )
#        else
#            pragma comment( lib, "sfml-system-s.lib" )
#        endif
#    endif
#endif

The "s" in the library-path stands here for "the c-runtime is linked statically".

What I'm facing: You can't compile your app with the option "multithreaded debug" and link to sfml statically. And you'll propably need 6 libs instead of 4

I'm pretty tired right now so I can't think of a possible solution since the option is given to link to sfml statically as well as dynamically.

edit: Got the right macros/definitions:

Code: [Select]


// Needs to get into a header-file, only for static linking against your lib
#ifdef _MSVC
#ifdef _DEBUG
#    ifdef _DLL
#       pragma comment( lib, "bla_debug_dynamic_crt.lib" )
#    else
#       pragma comment( lib, "bla_debug_static_crt.lib" )
#    endif
#else
#    ifdef _DLL
#       pragma comment( lib, "bla_release_dynamic_crt.lib" )
#    else
#       pragma comment( lib, "bla_release_static_crt.lib" )
#    endif
#endif
#endif

General discussions / nullptr

« on: August 18, 2008, 04:03:58 pm »

I'm sure you heard about C++0x, which comes along with a typesafe nullptr. In some open-std-proposal (Link), the typesafe nullptr to use in the current standard is introduced, take a look:

Code: [Select]


const    // this is a const object...
class {
public:
    template<class T>    // convertible to any type
    operator T*() const    // of null non-member
    { return 0; }    // pointer...

    template<class C, class T>  // or any type of null
    operator T C::*() const    // member pointer...
    { return 0; }

private:
    void operator&() const;    // whose address can't be taken
} nullptr = {};    // and whose name is nullptr

or, to save lines and chars:

Code: [Select]


const class {
public:
    template<class T> operator T*() const  {return 0;}
    template<class C, class T> operator T C::*() const  {return 0;}
private:
    void operator&() const;
} nullptr = {};

It's just a very practical thingy which solves the NULL-problematic:

Code: [Select]


void foo( int some_value );
void foo( int* some_pointer );

foo( 0 );       // calls foo(int)
foo( NULL );    // calls foo(int)
foo( nullptr ); // calls foo(int*)

I just wanted to tell you about it in case you didn't know and want to use it

General discussions / Hiding the <windows.h>

« on: July 15, 2008, 01:33:06 pm »

Hi!

I just have a suggestion how to get rid of the windows.h-includes in the sfml-header-files (like in thread.hpp or mutex.hpp).

The problem I have is that the windows.h massively pollutes the global namespaces, first by hundreds of functions and types and second, even worse, by dozens of macros like "max" (which prohibits the use of std::max).

The solution I propose is the following:

The windows.h in the header-files is needed only (as far as I see it) for win-types like "HANDLE" or "CRITICAL_SECTION" which are class-members of classes like sf::Thread or sf::Mutex.
So, if we want to get rid of the windows.h in the header-files, we'll have to replace those variable-types by types which aren't declared in the windows.h.
Replacing the HANDLE-type is easy since it's just a typedef to a pointer to something. We just would have to replace "HANDLE" in the header-file by "void*", include the windows.h in the cpp-file instead of the header and cast around (cast a lot, I admit) the void* to HANDLE in the cpp-file at every access to this variable.

Replacing ODTs like CRITICAL_SECTION is quite more complicated since this is a structure with actual members. My suggestion is to declare a private binary-equal structure inside the class; the substitude-structure of course must contain types like long, int and whatever. Since the winapi-functions always take pointers to structures like CRITICAL_SECTION, a simple cast again should do the thing as long as our replacement-structure is at least as big (in size in bytes) as the original CRITICAL_SECTION.

So: What do you think of this?

edit: I suppose that replacing the "CRITICAL_SECTION"-type could be done by just using "char[24]" and something equal to "BOOST_STATIC_ASSERT( sizeof(cs_mem_var) >= sizeof(CRITICAL_SECTION )" in the implementation-file.

edit: As far as I can see, only 3 header-files include the windows.h (SocketHelper, Mutex, Thread). I could do it and send someone the new sources if someone would like that.

edit: Ok, at least the the min- and max- macros from windows.h are prohibited with #define NOMINMAX, nevertheless there are enough other macros.

Pages: [1]