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.

Messages - Badestrand

Pages: [1] 2

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, 06:44:24 pm »

By the way, the Windows Filesystem doesn't combine characters

Code: [Select]


#include <fstream>
int main()
{
	std::ofstream(L"\u00e4");
	std::ofstream(L"\u0061\u0308");
}

Feature requests / Unicode-files and Normalization Forms

« on: November 30, 2008, 02:40:06 pm »

Quote from: "T.T.H."

One warning: implementing Unicode right is a really, really, really big task and is definitely out of bounds of SFML. As far as I know the only library doing Unicode stuff completely right is ICU, an open source library powered by IBM.

You are right, there is no way to provide a fully correct unicode-implementation in SFML. However, nevertheless SFML can provide some basic functionality which covers at least the most common european unicode-operations.

Feature requests / Unicode-files and Normalization Forms

« on: November 30, 2008, 02:37:11 pm »

Quote from: "Laurent"

I don't know much about normalization forms. I understand the concept, but what are they used for?

With having combining characters displayed in their combined form, it's for example easier to determine a string's length (currently only the number of codepoints, not the number of characters are counted). Additionally, many programs can't handle them correctly and comparison get's messy, too (ok, unicode-string-comparisons are messy either way).

edit: Maybe NFs are too complicated but a plain helper-function which combines the most basic european combining characters could be achievable. With this, we don't claim supporting NFs with supporting only parts of it.

edit2: One could provide combination-support for the languages covered by Latin-1, which are quite a few. This also would make a clean and simple implementation possible since there'd be only ~80 characters to combine.

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 / 64 bit linux binary

« on: September 14, 2008, 12:22:33 am »

Quote from: "krav"

The problem with the "None" is that i cant compile the project

Maybe you could try a "#undef None" before the enum, if it compiles you know what to search for.

General discussions / Libs + Dlls for Visual C++

« on: September 11, 2008, 09:00:58 am »

Quote from: "Laurent"

I'm not a huge fan of automatic linking with VC++ pragmas.

For a specific reason or just as general feeling (I'm asking just because I'm curious)?

Quote from: "Laurent"

People (especially beginners) are already confused between debug / release / static / dynamic versions, I don't want to add more to this confusion.

Hm, but don't the pragmas just take any sorrows off the beginners? I mean, they don't have to tell their compiler whether/with which lib they want to link (especially when you switch the strange standard-configuration above to "default-static", they won't even need a dll).

Quote from: "Laurent"

But anyway, thanks for your feedback

But I'm feeling a little dumb right now - I thought you may not know about the pragma-import since they're not used in sfml; I just assumed that you're mainly programming with gcc under linux so you may not know much about the MSVC and therefore not about the pragmas - On the other hand, the sfml-library is definitely not a standard-linux library :lol: I had to use and work on some linux-libraries a few days ago and I can tell you: I was a damn mess. ~7 files of C-code with each containing ~3500 lines of code :twisted:

General discussions / Re: Where to learn 3d programming

« on: September 11, 2008, 08:44:54 am »

Quote from: "ravenheart"

well at university i dont really

I know that lot's of students just do not understand this but it is just not the job of an university to teach programming. First, you need years to learn und mostly learn by doing not by getting told. Second, you will switch between programming languages so there is no sense to learn a specific one at university.

Btw, as fas as I know it's more common to say "computer science" in english

Quote from: "ravenheart"

so i wonder where can i learn how to0 use opengl do gamesprogreamming, etc

*Link to tons of tutorials*

General discussions / Libs + Dlls for Visual C++

« on: September 11, 2008, 05:08:18 am »

This might be a possible solution:

sfml-system-library-files in SFML/SFML-1.3/lib/vc2005/:

Code: [Select]


sfml-system-stat-s-d.lib // linked statically against SFML; user's app: static crt & debug
sfml-system-stat-s.lib   // linked statically against SFML; user's app: static crt & release
sfml-system-stat-d.lib   // linked statically against SFML; user's app: dynamic crt & debug
sfml-system-stat.lib     // linked statically against SFML; user's app: dynamic crt & release
sfml-system-d.lib        // linked dynamically against SFML; user's app on debug
sfml-system.lib          // linked dynamically against SFML; user's app on release

Place this in the sfml-system-header-file or make it an extra include-file which is included in sfml-system.hpp:

Code: [Select]


#ifdef _MSVC
#    if defined(SFML_SYSTEM_STATIC) || defined(SFML_STATIC)
#        ifdef _DEBUG
#            ifdef _DLL
#               pragma comment( lib, "sfml-system-stat-d.lib" )
#            else
#               pragma comment( lib, "sfml-system-stat-s-d.lib" )
#            endif
#        else
#            ifdef _DLL
#               pragma comment( lib, "sfml-system-stat.lib" )
#            else
#               pragma comment( lib, "sfml-system-stat-s.lib" )
#            endif
#        endif
#    else
#        ifdef _DEBUG
#            pragma comment( lib, "sfml-system-d.lib" )
#        else
#            pragma comment( lib, "sfml-system.lib" )
#        endif
#    endif
#endif

So when a user wants to link to SFML dynamically, he has nothing to do - including the "sfml-system.hpp" will automatically link his app against the DLL (sfml-system-d.dll or sfml-system.dll).

If a user wants to link statically to the SFML, he has to specify SFML_SYSTEM_STATIC (or SFML_STATIC for each SFML-module being linked statically) at the preprocessor-tab in the application's configuration. Libraries get linked all automatically, isn't this cool?

Of course all this applies to Visual Studio-applications only!

PS: Changes according the other modules are analogue and maybe it should be the other way around, that you have to specify this extra-preprocessor-definition (SFML_STATIC) for dynamic linking instead?

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, 05:09:22 pm »

- empty post -

General discussions / Hiding the <windows.h>

« on: July 15, 2008, 04:28:49 pm »

Quote from: "Laurent"

I usually don't like substituting system specific types with primitive ones, but it seems you've strongly checked this one and apparently it's safe to replace with a pointer type, so I'll give it a try.

Juchu, great!

Quote from: "Laurent"

Thanks for your help

It's also my profit

But there's another one: fd_set in SelectorBase.hpp in which the SOCKET-type is also used. Generally it should be no problem to substitude fd_set's SOCKET with the pointer but I don't know how or whether it conflicts with the linux or mac version since this substitution needs to take place in the SelectorBase.hpp-file. Maybe you'll need an plattform-dependent extra-include for such types? I guess this also would it make simpler to switch between the windows.h-version and the substitution-version, something like:

Code: [Select]


// SystemSpecifics.hpp for the windows-compilement
#define MAKE_SUBSTITUTIONS

#ifdef MAKE_SUBSTITUTIONS
    typedef void* HANDLE;
    typedef void* SOCKET;
    typedef ... fd_set;
#else
    #include <winsock2.h>
    #include <windows.h>
#endif

But I didn't think long enough about this so there may be some contras...

General discussions / Hiding the <windows.h>

« on: July 15, 2008, 03:50:01 pm »

Quote from: "Laurent"

It's needed for the SOCKET type definition, which relies on non-standard 64 bits compiler extensions so it can't be easily replaced.

I don't think so. Following the SOCKET-definition you can find

Code: [Select]

typedef UINT_PTR SOCKET;

If we believe a comment in my basetsd.h-file

Code: [Select]

// The INT_PTR is guaranteed to be the same size as a pointer.  Its
// size with change with pointer size (32/64).  It should be used
// anywhere that a pointer is cast to an integer type. UINT_PTR is
// the unsigned variation.

, then SOCKET is as wide as a pointer so it should be possible to represent the SOCKET-type be void*.

Btw, following the definition for UINT_PTR you can find

Code: [Select]

#if defined(_WIN64)
    typedef unsigned __int64 UINT_PTR;
#else
    typedef _W64 unsigned int UINT_PTR, *PUINT_PTR;
#endif

// with

#if !defined(__midl) && (defined(_X86_) || defined(_M_IX86)) && _MSC_VER >= 1300
    #define _W64 __w64
#else
    #define _W64
#endif

// _MSC_VER>=1300 is Visual C++ .NET 2002 upwards (see http://forums.msdn.microsoft.com/en/vcgeneral/thread/17a84d56-4713-48e4-a36d-763f4dba0c1c/)

__w64 is just a compiler-extension which doesn't influence the type it's used with:

Quote from: "MSDN"

The __w64 keyword lets you mark variables, such that when you compile with /Wp64 the compiler will report any warnings that would be reported if you were compiling with a 64-bit compiler.

Any typedef that has __w64 on it must be 32 bits on x86 and 64 bits on ia64.

The __w64 modifier should be specified on any typedefs that change size between 32 bit and 64 bit platforms. For any such type, __w64 should appear only on the 32-bit definition of the typedef.

General discussions / Hiding the <windows.h>

« on: July 15, 2008, 02:39:18 pm »

Would it be possible to ban the windows.h at least from the packages where OpenGl is not used? I personally use the system and network packages only so there should be no need for OpenGL.

Pages: [1] 2