> 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 i
>> 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 anyth
INTVAL, 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 an
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'
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
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 t
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. T
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?
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
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 th
# New Ticket Created by Mark Glines
# Please include the string: [perl #43241]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=43241 >
include/parrot/string.h contains 2 typedefs for the same thing: STRING
and Str
nd 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.
--
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: interprete
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 em
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 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
Outside the core there'll
# be a prepended Parrot_.
#
# I don't want any postfix _t. Or any 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* b
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
>'str
"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 th
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
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 s
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 that extends to
> # struct
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 sti
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
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 potenti
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.
--
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/co
To: Dan Sugalski <[EMAIL PROTECTED]>,
[EMAIL PROTECTED]
Subjec
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 things will be in lower case with a leading cap.
>> No data has a Parrot_ prefix--that'
>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
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
> #
# > # Oy vay!, none of which 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-struc
which 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&
lear
# > # consensus. (We got sidetracked 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
# > typedef
racked 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!, non
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
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]
37 matches
Mail list logo
