On 5 Dec, Sven Neumann wrote:
> if we'd use a programming language that would properly support ranged
> types, it'd be a cleanup. C however doesn't assure that. If the
> program would throw a signed exception if a negative value is ever
> assigned to an unsigned variable, we'd indeed be able to
On Wed, Dec 05, 2001 at 01:11:56AM +0100, [EMAIL PROTECTED] wrote:
> I say using a type that represents the actual type of the value
> closely is a feature and not a bug. What wrong about seing:
> Hey, this value is supposed to be unsigned?
Because that's not what "unsigned" does in C. Unsigned
Hi,
[EMAIL PROTECTED] writes:
> > but you continue to state that it makes the code cleaner which it
> > clearly doesn't.
>
> I say using a type that represents the actual type of the value
> closely is a feature and not a bug. What wrong about seing:
> Hey, this value is supposed to be unsigned
On 5 Dec, Sven Neumann wrote:
> but you continue to state that it makes the code cleaner which it
> clearly doesn't.
I say using a type that represents the actual type of the value
closely is a feature and not a bug. What wrong about seing:
Hey, this value is supposed to be unsigned?
This is a
From: [EMAIL PROTECTED]
Date: Tue, 4 Dec 2001 22:08:01 +0100 (CET)
--- paint-funcs.c.orig Thu Nov 29 14:17:47 2001
+++ paint-funcs.cTue Dec 4 21:53:49 2001
@@ -343,7 +343,8 @@
gdouble sigma2;
gdouble l;
gint temp;
- gint i, n;
+ guint
Hi,
[EMAIL PROTECTED] writes:
> But you also do read my mails, do you? And I said clearly that it might
> make a difference in larger functions not that it necessarily betters
> anything.
but you continue to state that it makes the code cleaner which it clearly
doesn't.
> Example? Ok, here y
On 4 Dec, Sven Neumann wrote:
>> Check the code if you don't believe it.
> Sorry, but that's exactly what I did before I posted the reply and I'm
> asking you to do that too. A simple benchmark prooves that the example
> you gave is wrong since the use of unsigned variables doesn't make any
>
On Tue, Dec 04, 2001 at 12:24:34AM +0100, Sven Neumann wrote:
> > I've applied exactly this scheme to tile_manager_get_tile_num () in
> > tile-manager.c and together with replacing the ongoing errorchecking
> > throughout the callees was able to save a whooping 480 bytes in object
> > size on PP
On Tue, Dec 04, 2001 at 01:39:36PM +0100, [EMAIL PROTECTED] wrote:
> I'm talking about nested function calls. If a function deep inside fails
> it should be handled as quickly as possible instead of propagating it
> through the code.
Uh, this is C, not Scheme. We don't throw exceptions. Calli
On Tue, Dec 04, 2001 at 11:34:59AM +0100, Sven Neumann wrote:
> the side effects of unsigned integers are not what people are used to
> think about when designing an algorithm. You are changing the
> mathematical base in an unneeded and hardly foreseeable way. Code that
> looks correct and used to
Hi Rebecca,
[EMAIL PROTECTED] (2001-12-04 at 1737.58 +0100):
>
> Can't we all bask in the gimp love?
>
Not to split hairs, but isn't it gimplove with no space?
carol
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mail
On Tue, Dec 04, 2001 at 02:17:06PM +0100, [EMAIL PROTECTED] wrote:
> agains 0 for example than against negativeness and this part also plays
> a role when returning 0 or non-null instead of a negative value.
Sorry, but before you continue with all this, ehrm, wrongness, would you
please first che
Hi,
[EMAIL PROTECTED] writes:
> On 4 Dec, Sven Neumann wrote:
>
> > this is not true. Please stop spreading this nonsense about unsigned
> > integers being more performant than signed ones. Go and write yourself
> > a simple benchmark for the code you mentioned above and you will
> > notice th
On 4 Dec, Sven Neumann wrote:
> this is not true. Please stop spreading this nonsense about unsigned
> integers being more performant than signed ones. Go and write yourself
> a simple benchmark for the code you mentioned above and you will
> notice that it doesn't make any difference at all.
H
On 3 Dec, Robert L Krawitz wrote:
> By how much?
Depends on the code and the compiler. And the range I'm talking about
is usually between 0 and 50% improvement in both code and size.
> If it can't be measured, it's probably not enough to be
> worthwhile.
Aside from the gains it's IMHO also cl
On 3 Dec, Robert L Krawitz wrote:
> Why? If a function is explicitly documented as returning an error,
> it's the caller's responsibility to handle it.
Right.
> The callee often doesn't know the high level context to handle it in a
> useful fashion.
I'm talking about nested function calls. I
Hi,
[EMAIL PROTECTED] writes:
> IMHO not because you're abusing the real value for errors and thus one
> variable for 2 purposes which is a bad idea and using signed integers is
> dragging down performance.
>
> It is also a bad idea to use signed integers for most loops for example;
> unsigned
From: [EMAIL PROTECTED]
Date: Tue, 4 Dec 2001 02:01:22 +0100 (CET)
On 4 Dec, Sven Neumann wrote:
> Using them for error reporting is definitely a bad idea. Using a
> negative value to indicate that a value has not been set and needs to
> be computed is IMO a reasonable usage.
From: [EMAIL PROTECTED]
Date: Tue, 4 Dec 2001 01:57:26 +0100 (CET)
On 4 Dec, Sven Neumann wrote:
> Using them for error reporting is definitely a bad idea. Using a
> negative value to indicate that a value has not been set and needs to
> be computed is IMO a reasonable usage.
On 4 Dec, Sven Neumann wrote:
> Using them for error reporting is definitely a bad idea. Using a
> negative value to indicate that a value has not been set and needs to
> be computed is IMO a reasonable usage.
On a side note: I found it quite often that the return value is set
to something in c
On 4 Dec, Sven Neumann wrote:
> Using them for error reporting is definitely a bad idea. Using a
> negative value to indicate that a value has not been set and needs to
> be computed is IMO a reasonable usage.
IMHO not because you're abusing the real value for errors and thus one
variable for 2
Hi,
[EMAIL PROTECTED] writes:
> However I see much room for improvement here. The values I changed
> to unsigned are likely meant to be unsigned like sizes, distances or
> heights or widths. And those are frequently used in loops like
>
> int i;
> for (i = 0; i < width; i++)
> foo ();
>
> if
Hi,
Nathan C Summers <[EMAIL PROTECTED]> writes:
> > BTW: It would have been a single command for me to revert the changes
>
> When Gimp first moved to CVS, and access to the source tree went from a
> strong central maintainer to many people with CVS access, the reason I was
> told that it wou
On 3 Dec, Nathan C Summers wrote:
> This may be a bug when used with unsigned numbers, but it certainly is
> a valid and acceptable approach to go out of range with signed
> numbers, which is what the program was using. Since the MAX macro
> returns a 1 for all nonpositive numbers, it's not a p
On 3 Dec, Michael Natterer wrote:
> This is not a bug in the code, it's only a bug if the code uses
> unsigned. Why on earth should we introduce side conditions that make
> using perfectly ok code like above buggy? Using signed is just
> defensive programming, using unsigned introduces side effe
[EMAIL PROTECTED] writes:
> > If width is unsigned and 10, then:
> >
> >int new_width = MAX (width - 15, 1);
> >
> > produces 4294967291, not 1.
>
> This is clearly a bug in the code. There are sizes which are by
> definition unsigned and code computes an negative value this is
> about
On 3 Dec, Sven Neumann wrote:
> you recently checked in a huge change to GIMP that we (Mitch and me)
> have been very unhappy with. In the meantime, I have gone through the
> hassle of looking at every single line of your changes and I have
> reverted most of it. Here are the reasons, why we thi
27 matches
Mail list logo
