It looks like those comments in platform_limits.h are out-of-place.
PARROT_INTVAL_MIN and PARROT_INTVAL_MAX are defined in
include/parrot/config.h, although the definition may not be as flexible
as the macros in perl.h that Nicholas mentioned. It might be beneficial
to incorporate them into
of
hard to work with them in some respects. All integral typedefs should
have
min/max macros. Syntax not a big deal, it can be fixed later, just
don't
break anything when introducing them.
Nothing has happened on this ticket since it was introduced in 2006. Do
we need MIN/MAX
It's great to have INTVAL and UINTVAL, but without MAX_INTVAL it's kind of
hard to work with them in some respects. All integral typedefs should
have
min/max macros. Syntax not a big deal, it can be fixed later, just don't
break anything when introducing them.
Nothing has happened
On Mon Jul 17 11:59:47 2006, chip wrote:
It's great to have INTVAL and UINTVAL, but without MAX_INTVAL it's kind of
hard to work with them in some respects. All integral typedefs should
have
min/max macros. Syntax not a big deal, it can be fixed later, just don't
break anything when
On Mon Jun 18 15:03:31 2007, petdance wrote:
On Jun 18, 2007, at 11:28 AM, Mark Glines (via RT) wrote:
Here's a patch to consolidate that, and standardize on STRING (based
on the fact that it's used *much* more often than String is).
And also isn't String a standard C++ class?
I've
Andy Lester [EMAIL PROTECTED] writes:
| On Jun 18, 2007, at 11:28 AM, Mark Glines (via RT) wrote:
|
| Here's a patch to consolidate that, and standardize on STRING (based
| on the fact that it's used *much* more often than String is).
|
| And also isn't String a standard C++ class?
No. The
On Tue, 19 Jun 2007 00:33:23 -0700
Paul Cochrane via RT [EMAIL PROTECTED] wrote:
On Mon Jun 18 15:03:31 2007, petdance wrote:
On Jun 18, 2007, at 11:28 AM, Mark Glines (via RT) wrote:
Here's a patch to consolidate that, and standardize on STRING
(based on the fact that it's used
On Jun 19, 2007, at 2:33 AM, Paul Cochrane via RT wrote:
Does this close this ticket, or are there still outstanding instances?
No, that closes it. Thanks for taking care of it.
--
Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
# New Ticket Created by Mark Glines
# Please include the string: [perl #43241]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=43241
include/parrot/string.h contains 2 typedefs for the same thing: STRING
and String
On Monday 18 June 2007 09:28:13 Mark Glines wrote:
include/parrot/string.h contains 2 typedefs for the same thing: STRING
and String. STRING is used everywhere; String is used occasionally.
they are interchangeable. This confused me at first, because I thought
String was the String PMC
On Jun 18, 2007, at 11:28 AM, Mark Glines (via RT) wrote:
Here's a patch to consolidate that, and standardize on STRING (based
on the fact that it's used *much* more often than String is).
And also isn't String a standard C++ class?
I've applied your patch. Thanks.
--
Andy Lester = [EMAIL
to work with them in some respects. All integral typedefs should have
min/max macros. Syntax not a big deal, it can be fixed later, just don't
break anything when introducing them.
--
Chip Salzenberg [EMAIL PROTECTED]
C++ automatically generates a typedef name when it sees struct Foo { .. }
We have a few places that name the typedef with the same name
as the tag (which I don't like as style anyway), and its causing problems
when trying to compile a C++ extension lib with parrot headers.
One example:
We're still all over the place with typedef name formats. We've FOO, Foo,
and foo_t. We tried to hash this out before, but we didn't come to a clear
consensus. (We got sidetracked by typedeffing pointers to typedefs.)
What's it going to be?
--
Bryan C. Warnock
[EMAIL PROTECTED]
Bryan C. Warnock:
# We're still all over the place with typedef name formats.
# We've FOO, Foo,
# and foo_t. We tried to hash this out before, but we didn't
# come to a clear
# consensus. (We got sidetracked by typedeffing pointers to typedefs.)
#
# What's it going to be?
Parrot_Foo
to typedefs.)
#
# What's it going to be?
Parrot_Foo for external names, FOO for internal names, struct
parrot_foo_t for struct names. Now let's argue about if Parrot_Foo is
typedefed as a pointer or not. ;^)
Oy vay!, none of which match PDD 07.
Shall we add parrot_foo_e for enums? (Which I'd
by typedeffing pointers
# to typedefs.)
# #
# # What's it going to be?
#
# Parrot_Foo for external names, FOO for internal names, struct
# parrot_foo_t for struct names. Now let's argue about if
# Parrot_Foo is
# typedefed as a pointer or not. ;^)
#
# Oy vay!, none of which match PDD 07.
I
that it probably should. I don't mind Parrot_Foo for externals -
that's good. We went around and around on INTVAL v Intval, which, by
itself, I couldn't care less about. However, if you're saying non-struct
typedefs are supposed to be FOO, I don't want to stare at a page of variable
types yelling at me
match PDD 07.
#
# Except that it probably should. I don't mind Parrot_Foo for
# externals -
# that's good. We went around and around on INTVAL v Intval, which, by
# itself, I couldn't care less about. However, if you're
# saying non-struct
# typedefs are supposed to be FOO, I don't want to stare
At 10:02 AM -0500 3/22/02, Bryan C. Warnock wrote:
We're still all over the place with typedef name formats. We've FOO, Foo,
and foo_t. We tried to hash this out before, but we didn't come to a clear
consensus. (We got sidetracked by typedeffing pointers to typedefs.)
All Parrot typedef'd
by typedeffing pointers to typedefs.)
All Parrot typedef'd things will be in lower case with a leading cap.
No data has a Parrot_ prefix--that's saved for the embedding and
extending headers. The sole exception is the PMC, and only because
that's an abbreviation so it's appropriate. That means
come to a
clear
consensus. (We got sidetracked by typedeffing pointers to typedefs.)
All Parrot typedef'd things will be in lower case with a leading cap.
No data has a Parrot_ prefix--that's saved for the embedding and
extending headers. The sole exception is the PMC, and only because
To: Dan Sugalski [EMAIL PROTECTED],
[EMAIL PROTECTED]
Bryan.Warnock@cacc:
pita.comSubject: Re: typedefs
On Friday 22 March 2002 11:46, Dan Sugalski wrote:
That's fine. Throw in typedefs for both ways to start, so we can do
this incrementally, if you would.
Index: config_h.in
===
RCS file: /home/perlcvs/parrot/config_h.in,v
At 11:53 AM -0500 3/22/02, Bryan C. Warnock wrote:
On Friday 22 March 2002 11:46, Dan Sugalski wrote:
That's fine. Throw in typedefs for both ways to start, so we can do
this incrementally, if you would.
Applied, thanks.
--
Dan
Brent Dax [EMAIL PROTECTED] writes:
Parrot_Foo for external names, FOO for internal names, struct
parrot_foo_t for struct names.
POSIX reserves all types ending in _t. I'm not sure that extends to
struct tags, but it may still be better to use _s or something else
instead to avoid potential
Russ Allbery:
# Brent Dax [EMAIL PROTECTED] writes:
# Parrot_Foo for external names, FOO for internal names, struct
# parrot_foo_t for struct names.
#
# POSIX reserves all types ending in _t. I'm not sure that extends to
# struct tags, but it may still be better to use _s or something else
#
On Friday 22 March 2002 17:53, Russ Allbery wrote:
Brent Dax [EMAIL PROTECTED] writes:
Parrot_Foo for external names, FOO for internal names, struct
parrot_foo_t for struct names.
POSIX reserves all types ending in _t. I'm not sure that extends to
struct tags, but it may still be
Brent Dax [EMAIL PROTECTED] writes:
Russ Allbery:
# POSIX reserves all types ending in _t. I'm not sure that extends to
# struct tags, but it may still be better to use _s or something else
# instead to avoid potential problems.
My understanding is that it only reserves types that start
Bryan C. Warnock:
# On Friday 22 March 2002 18:05, Brent Dax wrote:
# Russ Allbery:
# # Brent Dax [EMAIL PROTECTED] writes:
# # Parrot_Foo for external names, FOO for internal names, struct
# # parrot_foo_t for struct names.
# #
# # POSIX reserves all types ending in _t. I'm not sure
Bryan C. Warnock wrote:
On Friday 22 March 2002 17:53, Russ Allbery wrote:
Brent Dax [EMAIL PROTECTED] writes:
Parrot_Foo for external names, FOO for internal names, struct
parrot_foo_t for struct names.
POSIX reserves all types ending in _t. I'm not sure that extends to
At 3:53 PM -0800 3/22/02, Brent Dax wrote:
Bryan C. Warnock:
# Besides, what's the probability it'll be a problem if we prefix all
# struct names with 'parrot_'?
#
# You don't really want to do that, do you?
Yes, in fact, I do. In the general case, you will never have to use the
'struct'
other pre or post fix inside the
# core. I don't see the point, honestly.
How about differentiating between struct and non-struct versions of
things?
At least the names of structs *must* be externally visible. Otherwise
we can't define external typedefs in terms of them. If the names
On Fri, Mar 22, 2002 at 11:52:16AM -0500, Melvin Smith wrote:
On Friday 22 March 2002 11:36, Dan Sugalski wrote:
At 10:02 AM -0500 3/22/02, Bryan C. Warnock wrote:
I'm up in the air as to whether any of the core routines should have
a Parrot prefix--I'm thinking not, as I don't think any
On Sat, Mar 23, 2002 at 12:55:00AM +0100, Segher Boessenkool wrote:
Besides, struct etc. are their own namespace, aside from the normal
variables/functions namespace. No need for any pre/postfix at all.
Until someone wishes to embed the public headers into a C++ program.
Or finds themselves
On Friday 22 March 2002 19:40, Nicholas Clark wrote:
On Sat, Mar 23, 2002 at 12:55:00AM +0100, Segher Boessenkool wrote:
Besides, struct etc. are their own namespace, aside from the normal
variables/functions namespace. No need for any pre/postfix at all.
Until someone wishes to embed
36 matches
Mail list logo
