On Wed, 24 Oct 2007, Staffan Gimker wrote:
> What's the point of coming up with a new set of typedefs?
> inttypes.h/stdint.h is a part of C99 (although admittedly not a part of the
> current C++ standard, I *think* it will be part of C++0x). Furthermore,
> uint32_t is shorter to type than psg_uint32 and it's already a wide-spread
> way of solving the problem at hand.
The point is that there are parts of Player (and Stage) code that aren't
using C standard nor stdint.h standard for naming integer types. The worst
case is when sys/types.h naming is in use (and there are many places in
Player code for that). My header wasn't only for adding new naming
convention. It later uses this new typedefs to define typedefs that may be
missing if there's no stdint.h available or there's no uint/uchar/ushort
in sys/types.h. It means, when it is included, there's no need to make any
changes in Player and Stage code to make them int-portable.
> SDL/SDL_net seems like a pretty nasty dependency, or maybe just unnecessary.
I don't want to make SDL/SDL_net a hard dependency. I can't imagine
to link with libsdl Player binary supposed to work on embedded system. As
I proposed months ago, usage of SDL/SDL_net should be an optional
dependency for those who plan to use Player on Windows (as native binary)
or other exotic systems like that. For them, it would be a solution for
- threads (iff SDL thread model is enough)
- int typing
- shared object loading (plugins, i.e. Stage)
- some hardware access (sound, joystick)
I know that it's not much, all other hardware drivers won't built on
exotic systems, but sometimes their users just want to run Stage
simulation or use passthrough driver.
I'm planning to write OpenCV-based camera driver for all the systems that
have OpenCV library (it can cooperate with both v4l and VideoForWindows).
As long as there's no highly portable Player distribution, I see no
reason for starting this project.
> Unless Player is using any esoteric socket functions, sockets work almost the
> same on Windows as they do on unices.
As we say it in Poland: 'almost' makes the real difference.
> Usually, you can easily get socket code
> to compile and run on both Windows and UNIX if you're careful.
Yup, and I can do that different ways. Use of SDL_net is one of the
> On Wednesday 24 October 2007 14:09:32 Paul Osmialowski wrote:
>> Hi devels!
>> Please forgive me I'm attaching a file again, this time it is a new
>> feature rather than a patch so I see no point to put it on a tracker.
>> Some time ago I was trying to do a very first step for making Player
>> highly portable software. I was trying to compile some parts of it on
>> MinGW (I've replaced some pieces of code, for example BSD-socket function
>> calls with SDL_net function calls, Sun XDR function calls with my own
>> implementation of XDR based on glibc code, slightly depending on SDL
>> macros). The result was playerlibsdl - a set of libraries required to
>> build client-side applications natively on every system that have
>> SDL/SDL_net library (all UNIXes including QNX, BeOS, Windows and so on).
>> One of the most anoying issues was the way integer types was called by
>> different programmers. MinGW (and probably other non-UNIX systems) does
>> not support ALL naming conventions. I've realised that the names were
>> taken from:
>> - C Standard (which is good) (unsigned int)
>> - stdint.h (which is not that bad) (uint32_t)
>> - sys/types.h (which is totally bad) (uint)
>> - glib.h (fortunately only in glib/gtk/libgnomecanvas/xmms/-related code,
>> which is not that bad or even reasonable) (guint/guint32)
>> My proposal is to use only one naming convention: all integer types
>> prefixed with psg_:
>> psg_ptr (which means void *)
>> I've prepared header file which should be included by
>> libplayercore/player.h which I expect is included by all other Player
>> includes (I've checked libplayerc/playerc.h, and indeed it includes
>> I'm realistic, I know there's a lot of code that should be reworked with
>> that fashion, that's why at the end of my player_ints.h I've added so
>> called 'compatibility tricks'. Depending on what includes are in use they
>> add missing type definitions used in Player and Stage code, so for example
>> MinGW gcc will not yeld for them anymore.
>> Unfortunately, to make my header file work properly, there must be added a
>> test for sys/types.h in autoconf scripts. It relays on HAVE_SYS_TYPES_H
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> Playerstage-developers mailing list