[Spread-users] sp.h defines collitions

John Schultz jschultz at spreadconcepts.com
Thu Jun 27 13:25:27 EDT 2013


That is another good suggestion.  I'll see if I can work on setting up a bug tracking system.

In the mean time, everyone is welcome to work on issues they find and submit patches to us for consideration.

The problem here is that int16 and int32 are in the client library's public API.  Therefore, to maintain backwards compatibility we really do need those types to be defined by including sp.h.

Probably the best solution would to make autoconf smarter and to pull in more standard .h's from sp.h that define these types wherever possible and only define them ourselves as a last resort.

I think using a typedef rather than a #define should be fine (assuming another header doesn't #define that type too).  However, I believe most compilers will still choke on a repeated typedef, so that alone won't solve the issue.

Cheers!

-----
John Lane Schultz
Spread Concepts LLC
Phn: 301 830 8100
Cell: 443 838 2200

On Jun 27, 2013, at 12:52 PM, Marcelo San-Martin wrote:

Hi John,
How can others help you to get there? It would be nice if contributors could help providing changes, it would require a bug tracking system.

Thanks,
Marcelo

-----Original Message-----
From: John Schultz [mailto:jschultz at spreadconcepts.com] 
Sent: Thursday, June 27, 2013 7:51 AM
To: Marcelo San-Martin
Cc: spread-users at lists.spread.org
Subject: Re: [Spread-users] sp.h defines collitions

In general, we agree and have been trying to move away from such things.  However, these definitions have been part of the project for a long time and getting rid of these definitions now could break old code that depended on them.

We'll work on this and see if we can come up with a good solution.

Cheers!

-----
John Lane Schultz
Spread Concepts LLC
Phn: 301 830 8100
Cell: 443 838 2200

On Jun 24, 2013, at 8:29 PM, Marcelo San-Martin wrote:

Hi,
I don't know if there has been discussions about this file but I am having a lot of issues regarding #defines colliding with symbols, enum, and typedef defined in other libraries, for example:

# define int16 short
# define int32 int

Are these really necessary, type definitions using #define are not a good practice? 

Definitions like LOW_PRIORITY and HIGH_PRIORITY are very common, Wouldn't be better to have all this prefixed with "SPREAD_" instead?

Thanks,
Marcelo








_______________________________________________
Spread-users mailing list
Spread-users at lists.spread.org
http://lists.spread.org/mailman/listinfo/spread-users


_______________________________________________
Spread-users mailing list
Spread-users at lists.spread.org
http://lists.spread.org/mailman/listinfo/spread-users




More information about the Spread-users mailing list