Re: [Mono-dev] [PATCH] Int32.Parse
Hello,
Ok, then let's keep as you said. The attached patch applies what you
suggested, and also added a method to retrieve the so-often-used
FormatException (I think it was kind of insane to have the exception
being thrown from different places with exactly the same message).
Carlos.
El jue, 20-10-2005 a las 13:06 +0200, Zoltan Varga escribió:
Hi,
I think it would be a little bit easier to return the actual
exception to be thrown from the
TryParse methods as an out argument, instead of adding this
abstraction layer which
cannot return more helpful exceptions messages like Number '123' is
not valid. We should
also retain the tryParse argument so these exception objects are not
creared if it is true.
So for example:
internal bool Parse (String number, bool tryParse, out int result, out
Exception ex)
{
...
if (something_is_wrong) {
if (!tryParse)
ex = new ArgumentException ();
return false;
}
Zoltan
On 10/20/05, Carlos Alberto Cortez [EMAIL PROTECTED] wrote:
Hey,
Currently the Int32.TryParse method calls the Int32.Parse method, and
catches the exceptions. That's not the best behaviour, since
Int32.TryParse is designed to avoid the performance problems associated
with exception handling.
The attached patch proposes an approach to keep the result of the
parsing as an enum, and based on it the methods decide whether they
throw an exception or not.
I wanted you to take a look at it, since we need to decide the best
solution for this before changing the TryParse/Parse methods in other
types.
Carlos.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Index: Int32.cs
===
--- Int32.cs (revisión: 52018)
+++ Int32.cs (copia de trabajo)
@@ -179,7 +179,7 @@
return Parse (s, style, null);
}
- internal static void CheckStyle (NumberStyles style)
+ internal static bool CheckStyle (NumberStyles style)
{
if ((style NumberStyles.AllowHexSpecifier) != 0) {
NumberStyles ne = style ^ NumberStyles.AllowHexSpecifier;
@@ -188,24 +188,37 @@
if ((ne NumberStyles.AllowTrailingWhite) != 0)
ne ^= NumberStyles.AllowTrailingWhite;
if (ne != 0)
- throw new ArgumentException (
- With AllowHexSpecifier only +
- AllowLeadingWhite and AllowTrailingWhite +
- are permitted.);
+ return false;
}
+
+ return true;
}
- internal static int JumpOverWhite (int pos, string s, bool excp)
+ internal static bool JumpOverWhite (ref int pos, string s)
{
+ return JumpOverWhite (ref pos, s, true);
+ }
+
+ internal static bool JumpOverWhite (ref int pos, string s, bool report_error)
+ {
while (pos s.Length Char.IsWhiteSpace (s [pos]))
pos++;
- if (excp pos = s.Length)
-throw new FormatException (Input string was not in the correct format.);
+ if (report_error pos = s.Length)
+return false;
- return pos;
+ return true;
}
+ internal static int JumpOverWhite (int pos, string s, bool exc)
+ {
+ int p = pos;
+ if (!JumpOverWhite (ref p, s, exc))
+throw GetFormatException ();
+
+ return p;
+ }
+
internal static void FindSign (ref int pos, string s, NumberFormatInfo nfi,
ref bool foundSign, ref bool negative)
{
@@ -275,22 +288,33 @@
return Char.IsDigit (e);
}
- internal static bool Parse (string s, NumberStyles style, IFormatProvider fp, bool tryParse, out int result)
+ internal static Exception GetFormatException ()
{
+ return new FormatException (Input string was not in the correct format.);
+ }
+
+ internal static bool Parse (string s, NumberStyles style, IFormatProvider fp, bool tryParse, out int result, out Exception exc)
+ {
result = 0;
+ exc = null;
- if (s == null)
-if (tryParse)
- return false;
-else
- throw new ArgumentNullException ();
+ if (s == null) {
+if (!tryParse)
+ exc = GetFormatException ();
+return false;
+ }
+
+ if (s == null) {
+if (!tryParse)
+ exc = new ArgumentNullException ();
+return false;
+ }
- if (s.Length == 0)
-if (tryParse)
- return false;
-else
- throw new FormatException (Input string was not +
- in the correct format.);
+ if (s.Length == 0) {
+if (!tryParse)
+ exc = GetFormatException ();
+return false;
+ }
NumberFormatInfo nfi;
if (fp != null) {
@@ -300,7 +324,11 @@
else
nfi = Thread.CurrentThread.CurrentCulture.NumberFormat;
- CheckStyle (style);
+ if (!CheckStyle (style)) {
+if (!tryParse)
+ exc = new ArgumentException ();
+return false;
+ }
bool AllowCurrencySymbol = (style NumberStyles.AllowCurrencySymbol)
Re: [Mono-dev] [PATCH] Int32.Parse
Hi,
This looks cool. I think it would be easier to add an out ex
argument to CheckStyle
as well, instead of duplicating the exception message in three different places.
Zoltan
On 10/21/05, Carlos Alberto Cortez [EMAIL PROTECTED] wrote:
Hello,
Ok, then let's keep as you said. The attached patch applies what you
suggested, and also added a method to retrieve the so-often-used
FormatException (I think it was kind of insane to have the exception
being thrown from different places with exactly the same message).
Carlos.
El jue, 20-10-2005 a las 13:06 +0200, Zoltan Varga escribió:
Hi,
I think it would be a little bit easier to return the actual
exception to be thrown from the
TryParse methods as an out argument, instead of adding this
abstraction layer which
cannot return more helpful exceptions messages like Number '123' is
not valid. We should
also retain the tryParse argument so these exception objects are not
creared if it is true.
So for example:
internal bool Parse (String number, bool tryParse, out int result, out
Exception ex)
{
...
if (something_is_wrong) {
if (!tryParse)
ex = new ArgumentException ();
return false;
}
Zoltan
On 10/20/05, Carlos Alberto Cortez [EMAIL PROTECTED] wrote:
Hey,
Currently the Int32.TryParse method calls the Int32.Parse method, and
catches the exceptions. That's not the best behaviour, since
Int32.TryParse is designed to avoid the performance problems associated
with exception handling.
The attached patch proposes an approach to keep the result of the
parsing as an enum, and based on it the methods decide whether they
throw an exception or not.
I wanted you to take a look at it, since we need to decide the best
solution for this before changing the TryParse/Parse methods in other
types.
Carlos.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Status pages mix mested class members with declaring class members
Hi, Status pages mix mested class members with declaring class members. For example look at ImageList on http://mono.ximian.com/class-status/mono-HEAD-vs-fx-2/class-status-System.Windows.Forms.html Members Item, Keys, Add, AddRange, Contains, ContainsKey, IndexOf, IndexOfKey, Remove, RemoveByKey, SetKeyName are all members of ImageList.ImageCollection nested class. I don't know whether this is a limitation of corcompare of just a limitation of status page generator but should be corrected as there are a lot of public nested classes in the class library and their status cannot be seen correctly. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] ImageList: Simulate handle creation and add 2.0 members
Hi, This version should behave like MS.NET version. Note that I had to copy some MS.NET behavior that I would treat as bug but is required to identical behaviour. I added profile 2.0 members as well, that are mainly support functions for key based item access. And contains some modifications compared to the previous patch I submitted. For more information look at the diff. Please review the modifications, do some tests, and approve the patch. Kornél ImageList.cs.tar.gz Description: GNU Zip compressed data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Int32.Parse
Ok, let's keep that change too. Is it ok to commit? More comments? based
on this, I will work on change the impl of Parse in other types.
Carlos.
El vie, 21-10-2005 a las 12:59 +0200, Zoltan Varga escribió:
Hi,
This looks cool. I think it would be easier to add an out ex
argument to CheckStyle
as well, instead of duplicating the exception message in three different
places.
Zoltan
On 10/21/05, Carlos Alberto Cortez [EMAIL PROTECTED] wrote:
Hello,
Ok, then let's keep as you said. The attached patch applies what you
suggested, and also added a method to retrieve the so-often-used
FormatException (I think it was kind of insane to have the exception
being thrown from different places with exactly the same message).
Carlos.
El jue, 20-10-2005 a las 13:06 +0200, Zoltan Varga escribió:
Hi,
I think it would be a little bit easier to return the actual
exception to be thrown from the
TryParse methods as an out argument, instead of adding this
abstraction layer which
cannot return more helpful exceptions messages like Number '123' is
not valid. We should
also retain the tryParse argument so these exception objects are not
creared if it is true.
So for example:
internal bool Parse (String number, bool tryParse, out int result, out
Exception ex)
{
...
if (something_is_wrong) {
if (!tryParse)
ex = new ArgumentException ();
return false;
}
Zoltan
On 10/20/05, Carlos Alberto Cortez [EMAIL PROTECTED] wrote:
Hey,
Currently the Int32.TryParse method calls the Int32.Parse method, and
catches the exceptions. That's not the best behaviour, since
Int32.TryParse is designed to avoid the performance problems associated
with exception handling.
The attached patch proposes an approach to keep the result of the
parsing as an enum, and based on it the methods decide whether they
throw an exception or not.
I wanted you to take a look at it, since we need to decide the best
solution for this before changing the TryParse/Parse methods in other
types.
Carlos.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-dev] C# and SWT
Hello, Why you dont uses Gtk#? Is a nice toolkit and run under Linux and Windows (I am not sure about Mac). I have used GTK+ in the past, and liked it, but I'm really looking to use native widgets this time. In my experience, Mac users demand nothing less, and personally I think it looks better anyway. I appreciate that. There is an ongoing effort from Immendio to port Gtk to MacOS and use Quartz natively. This plus a rendering theme should get you must of the features you want. Sadly it wont hit the streets until next year. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [good] RE: [Mono-dev] C# and SWT
i am waiting for that gtk port to MacOS ... in the mean time .. I am using WX.Wigets (wx.net) which is native on linux,mac, and win32 its not nearly as powerful as using gtk+ direct, but it does work to produce an app to all three platforms now. And with wx.net it just involves including 2 dll's in your application deployment for windows and linux. But for mac as far as i have found, you have to tinker a bit more. I just have the mac users install the WX.net package (demo), then have them put my app in that structure, as i am not knowledgable about packaging for a Mac yet. -tl On Fri, 21 Oct 2005 13:30:07 -0400 Miguel de Icaza [EMAIL PROTECTED] wrote: Hello, Why you dont uses Gtk#? Is a nice toolkit and run under Linux and Windows (I am not sure about Mac). I have used GTK+ in the past, and liked it, but I'm really looking to use native widgets this time. In my experience, Mac users demand nothing less, and personally I think it looks better anyway. I appreciate that. There is an ongoing effort from Immendio to port Gtk to MacOS and use Quartz natively. This plus a rendering theme should get you must of the features you want. Sadly it wont hit the streets until next year. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [good] RE: [Mono-dev] C# and SWT
On 10/21/05, ted leslie [EMAIL PROTECTED] wrote: application deployment for windows and linux. But for mac as far as i have found, you haveto tinker a bit more. I just have the mac users install the WX.net package (demo),then have them put my app in that structure, as i am not knowledgable about packaging for a Mac yet. I've found that if you include the wx.NET libs from the Mac package alongside the actual app binaries in the .app directory structure the user isn't required to install anything. The only shortcoming is that the application is now substantially larger to distribute.-- Bigger 1:23This address if for mailing list traffic only. Please direct non-list correspondence to 0x90.org ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
