www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Numeric access to char[]

reply Peter Thomassen <info peter-thomassen.de> writes:
Hi,

how is it possible to work on the numeric value of a char[]? I'm interested
in bit shifting and arithmetic operations on the numeric value.

Thanks!
Peter
Aug 21 2006
next sibling parent reply nobody <nobody mailinator.com> writes:
Peter Thomassen wrote:
 Hi,
 
 how is it possible to work on the numeric value of a char[]? I'm interested
 in bit shifting and arithmetic operations on the numeric value.
 
 Thanks!
 Peter

I am pretty sure you can just treat a char as a ubyte. The char type is 8 bits and unsigned. However if it makes it easier for you then you might try this: int main(char[][] args) { ubyte[] num1 = cast(ubyte) args[0]; }
Aug 21 2006
next sibling parent reply Peter Thomassen <info peter-thomassen.de> writes:
nobody schrieb am Dienstag, 22. August 2006 00:54:
 how is it possible to work on the numeric value of a char[]? I'm
 interested in bit shifting and arithmetic operations on the numeric
 value.

I am pretty sure you can just treat a char as a ubyte. The char type is 8 bits and unsigned. However if it makes it easier for you then you might try this: int main(char[][] args) { ubyte[] num1 = cast(ubyte) args[0]; }

When casting to ubyte[], this works fine. But I actually meant the numeric value of char[], not the one of char. Do I need to construct it from the single chars, or can I, for example, right-shift a whole char[] by 1? Peter
Aug 21 2006
next sibling parent reply nobody <nobody mailinator.com> writes:
Peter Thomassen wrote:
 nobody schrieb am Dienstag, 22. August 2006 00:54:
 how is it possible to work on the numeric value of a char[]? I'm
 interested in bit shifting and arithmetic operations on the numeric
 value.

bits and unsigned. However if it makes it easier for you then you might try this: int main(char[][] args) { ubyte[] num1 = cast(ubyte) args[0]; }

When casting to ubyte[], this works fine. But I actually meant the numeric value of char[], not the one of char. Do I need to construct it from the single chars, or can I, for example, right-shift a whole char[] by 1? Peter

Sorry I misunderstood you! I am still not completely sure what you are after but I think it sounds likely you mean this: char[] ex = "azAZ"; // 'a' = 65 = 01000001 (binary) // 'z' = 90 = 01011010 (binary) // 'A' = 97 = 01100001 (binary) // 'Z' = 122= 01111010 (binary) 01000001 01011010 01100001 01111010 becomes (carries from one pos to the next) 00100000 10101101 00110000 10111101 instead of (right 1s fall off) 00100000 00101101 00110000 00111101 I am pretty sure the only likely candidate for that would have been std.bitarray but the docs don't include the shift operators: http://digitalmars.com/d/phobos/std_bitarray.html So you will have to do it manually. I would like to suggest that if you can pad the char[] to ensure its .length % 8 == 0 then you can cast it to a ulong and your shifting will be faster.
Aug 21 2006
parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
nobody wrote:
...
 
 So you will have to do it manually. I would like to suggest that if you 
 can pad the char[] to ensure its .length % 8 == 0 then you can cast it 
 to a ulong and your shifting will be faster.

Sure about ulong? In my spare time I made my own minimal Bignum implementation. I'm not sure about shifts, but for addition with carrying it was faster to use size_t (uint in this case) rather than ulong. I wonder if maybe the compiler could optimize it better if it didn't have to emulate 64 bit integers. Or my benchmark was borked.
Aug 22 2006
parent reply nobody <nobody mailinator.com> writes:
Chad J wrote:
 nobody wrote:
 ....
 So you will have to do it manually. I would like to suggest that if 
 you can pad the char[] to ensure its .length % 8 == 0 then you can 
 cast it to a ulong and your shifting will be faster.

Sure about ulong? In my spare time I made my own minimal Bignum implementation. I'm not sure about shifts, but for addition with carrying it was faster to use size_t (uint in this case) rather than ulong. I wonder if maybe the compiler could optimize it better if it didn't have to emulate 64 bit integers. Or my benchmark was borked.

I certainly could be wrong but I would be quite surprised. I would be interested to see what tests you ran that suggest addition with carry was faster.
Aug 23 2006
parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

nobody wrote:
 Chad J wrote:
 
 nobody wrote:
 ....

 So you will have to do it manually. I would like to suggest that if 
 you can pad the char[] to ensure its .length % 8 == 0 then you can 
 cast it to a ulong and your shifting will be faster.

Sure about ulong? In my spare time I made my own minimal Bignum implementation. I'm not sure about shifts, but for addition with carrying it was faster to use size_t (uint in this case) rather than ulong. I wonder if maybe the compiler could optimize it better if it didn't have to emulate 64 bit integers. Or my benchmark was borked.

I certainly could be wrong but I would be quite surprised. I would be interested to see what tests you ran that suggest addition with carry was faster.

This BigNum I made is very incomplete and probably slow. Changing the size of it's digits shouldn't do anything besides just that, though. I have attached 2 .d files, BigNum.d is the implementation, main.d is the benchmark. I compiled it with dmd -O -inline -release. At the top of BigNum.d there is an alias that I use to switch between size_t and ulong variables used in the computation. Here are my results. See main.d for details of the setup. Microseconds to complete 1000000 additions using size_t: 786779 776801 793653 783896 787937 789150 Microseconds to complete 1000000 additions using ulong: 866767 860499 866921 865791 860874 858154
Aug 25 2006
parent reply nobody <nobody mailinator.com> writes:
Chad J wrote:
 nobody wrote:
 Chad J wrote:

 nobody wrote:
 ....

 So you will have to do it manually. I would like to suggest that if 
 you can pad the char[] to ensure its .length % 8 == 0 then you can 
 cast it to a ulong and your shifting will be faster.

Sure about ulong? In my spare time I made my own minimal Bignum implementation. I'm not sure about shifts, but for addition with carrying it was faster to use size_t (uint in this case) rather than ulong. I wonder if maybe the compiler could optimize it better if it didn't have to emulate 64 bit integers. Or my benchmark was borked.

I certainly could be wrong but I would be quite surprised. I would be interested to see what tests you ran that suggest addition with carry was faster.

This BigNum I made is very incomplete and probably slow. Changing the size of it's digits shouldn't do anything besides just that, though. I have attached 2 .d files, BigNum.d is the implementation, main.d is the benchmark. I compiled it with dmd -O -inline -release. At the top of BigNum.d there is an alias that I use to switch between size_t and ulong variables used in the computation. Here are my results. See main.d for details of the setup. Microseconds to complete 1000000 additions using size_t: 786779 776801 793653 783896 787937 789150 Microseconds to complete 1000000 additions using ulong: 866767 860499 866921 865791 860874 858154

Thanks for taking the time to post this. It will be a little while before I can sit down and play with the code you sent so I thought I would give you my first impression. It looks like you have tested the time it takes to add a 20 "digit" number to an 18 "digit" number: BigDigit[20] test1; BigDigit[18] test2; You define these numbers as one of the two: alias size_t BigDigit; // for optimal performance alias ulong BigDigit; I think the easiest way to suggest the problem with your test is in finding how many bytes we are adding in each case: 20 * 4 = 80 bytes 20 * 8 = 160 bytes What your results actually seem to be saying is that treating char[160] as a ulong takes slightly longer than treating char[80] as a uint. I am still fairly convinced that if you test again with an equal number of bytes you should find that the ulong case will be faster. If you have a chance to run the test before me I would be interested to hear the results.
Aug 25 2006
parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

nobody wrote:
 Chad J wrote:
 
 nobody wrote:

 Chad J wrote:

 nobody wrote:
 ....

 So you will have to do it manually. I would like to suggest that if 
 you can pad the char[] to ensure its .length % 8 == 0 then you can 
 cast it to a ulong and your shifting will be faster.

Sure about ulong? In my spare time I made my own minimal Bignum implementation. I'm not sure about shifts, but for addition with carrying it was faster to use size_t (uint in this case) rather than ulong. I wonder if maybe the compiler could optimize it better if it didn't have to emulate 64 bit integers. Or my benchmark was borked.

I certainly could be wrong but I would be quite surprised. I would be interested to see what tests you ran that suggest addition with carry was faster.

This BigNum I made is very incomplete and probably slow. Changing the size of it's digits shouldn't do anything besides just that, though. I have attached 2 .d files, BigNum.d is the implementation, main.d is the benchmark. I compiled it with dmd -O -inline -release. At the top of BigNum.d there is an alias that I use to switch between size_t and ulong variables used in the computation. Here are my results. See main.d for details of the setup. Microseconds to complete 1000000 additions using size_t: 786779 776801 793653 783896 787937 789150 Microseconds to complete 1000000 additions using ulong: 866767 860499 866921 865791 860874 858154

Thanks for taking the time to post this. It will be a little while before I can sit down and play with the code you sent so I thought I would give you my first impression. It looks like you have tested the time it takes to add a 20 "digit" number to an 18 "digit" number: BigDigit[20] test1; BigDigit[18] test2; You define these numbers as one of the two: alias size_t BigDigit; // for optimal performance alias ulong BigDigit; I think the easiest way to suggest the problem with your test is in finding how many bytes we are adding in each case: 20 * 4 = 80 bytes 20 * 8 = 160 bytes What your results actually seem to be saying is that treating char[160] as a ulong takes slightly longer than treating char[80] as a uint. I am still fairly convinced that if you test again with an equal number of bytes you should find that the ulong case will be faster. If you have a chance to run the test before me I would be interested to hear the results.

Ah, good catch. That does turn the results around, now the ulong leads slightly instead of the other way around. Changed BigDigit[20] test1; BigDigit[18] test2; to ulong[20] test1; ulong[18] test2; w/ size_t: 880821 905326 871996 895222 897846 w/ ulong: 849123 848298 849372 852560 895887 Another thing with the test... random numbers. It probably won't matter much, but when using 64 bit digits, only the lo 32 bits get filled by phobo's rand() function, which means no carrying, ever. Also, it might be interesting to do extreme cases like where the numbers always have all of the bits set, which forces carrying all the time. I also noticed that I broke the unittest when I tried to free up any memory the carrying might have wasted, so I've fixed that and here's the new version. (This really didn't have an effect on speed, just correctness)
Aug 25 2006
parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
Brad Roberts wrote:
 
 Have any of you looked at the GMP library?  It's a highly optimized large 
 number library.  It supports both large integers and large floats.  
 Providing a D wrapper on top of it would be the direction I'd head in for 
 this sort of use case.
 
 Later,
 Brad

Hey thanks for that info. I didn't know that existed. I probably won't be writing any wrapper though, as the thing I wrote here was just for fun. Maybe I will if I ever seriously need a bignum library though.
Aug 25 2006
parent "John Reimer" <terminal.node gmail.com> writes:
On Fri, 25 Aug 2006 16:19:29 -0700, Chad J  
<gamerChad _spamIsBad_gmail.com> wrote:

 Brad Roberts wrote:
  Have any of you looked at the GMP library?  It's a highly optimized  
 large number library.  It supports both large integers and large  
 floats.  Providing a D wrapper on top of it would be the direction I'd  
 head in for this sort of use case.
  Later,
 Brad

Hey thanks for that info. I didn't know that existed. I probably won't be writing any wrapper though, as the thing I wrote here was just for fun. Maybe I will if I ever seriously need a bignum library though.

There's no need to make another one. :) A GMP wrapper was written long ago by Ben Hinkle: http://home.comcast.net/~benhinkle/gmp-d/ -JJR
Aug 27 2006
prev sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Tue, 22 Aug 2006 01:30:23 +0200, Peter Thomassen  
<info peter-thomassen.de> wrote:
 nobody schrieb am Dienstag, 22. August 2006 00:54:
 how is it possible to work on the numeric value of a char[]? I'm
 interested in bit shifting and arithmetic operations on the numeric
 value.

I am pretty sure you can just treat a char as a ubyte. The char type is 8 bits and unsigned. However if it makes it easier for you then you might try this: int main(char[][] args) { ubyte[] num1 = cast(ubyte) args[0]; }

When casting to ubyte[], this works fine. But I actually meant the numeric value of char[], not the one of char. Do I need to construct it from the single chars, or can I, for example, right-shift a whole char[] by 1?

Depends what exactly you're trying to do, perhaps this: import std.stdio; void main() { char[] c = "azAZ"; int val; val = (cast(int*)c.ptr)[0..1][0]; //DEBUG //writef("(%02d)%08b",c[0],c[0]); //writef(",(%02d)%08b",c[1],c[1]); //writef(",(%02d)%08b",c[2],c[2]); //writefln(",(%02d)%08b",c[3],c[3]); writefln("%032b",val); val >>= 1; writefln("%032b",val); } Regan p.s. nobody got the ascii values backward ('A' is 65, 'a' is 97) it's nobody's fault really.. nobody is to blame.. "nobody" I love the nick.. have you read the "Deverry" novels by "Katherine Kerr"? http://www.math.ttu.edu/~kesinger/deverry/kerr.biblio.html
Aug 22 2006
next sibling parent nobody <nobody mailinator.com> writes:
Regan Heath wrote:
 On Tue, 22 Aug 2006 01:30:23 +0200, Peter Thomassen 
 <info peter-thomassen.de> wrote:
 nobody schrieb am Dienstag, 22. August 2006 00:54:
 how is it possible to work on the numeric value of a char[]? I'm
 interested in bit shifting and arithmetic operations on the numeric
 value.

I am pretty sure you can just treat a char as a ubyte. The char type is 8 bits and unsigned. However if it makes it easier for you then you might try this: int main(char[][] args) { ubyte[] num1 = cast(ubyte) args[0]; }

When casting to ubyte[], this works fine. But I actually meant the numeric value of char[], not the one of char. Do I need to construct it from the single chars, or can I, for example, right-shift a whole char[] by 1?

Depends what exactly you're trying to do, perhaps this: import std.stdio; void main() { char[] c = "azAZ"; int val; val = (cast(int*)c.ptr)[0..1][0]; //DEBUG //writef("(%02d)%08b",c[0],c[0]); //writef(",(%02d)%08b",c[1],c[1]); //writef(",(%02d)%08b",c[2],c[2]); //writefln(",(%02d)%08b",c[3],c[3]); writefln("%032b",val); val >>= 1; writefln("%032b",val); } Regan p.s. nobody got the ascii values backward ('A' is 65, 'a' is 97) it's nobody's fault really.. nobody is to blame..

I sure did. :-)
 "nobody" I love the nick.. have you read the "Deverry" novels by 
 "Katherine Kerr"?
 http://www.math.ttu.edu/~kesinger/deverry/kerr.biblio.html
 

Not yet but I am always looking for good stuff to read. I would guess Nobody comes from Dead Man on some subconscious level: http://www.imdb.com/title/tt0112817/
Aug 22 2006
prev sibling parent reply Peter Thomassen <info peter-thomassen.de> writes:
<veröffentlicht & per Mail versendet>

Hi!

Regan Heath schrieb am Mittwoch, 23. August 2006 02:06:
 Depends what exactly you're trying to do, perhaps this:
 
 import std.stdio;
 
 void main()
 {
 char[] c = "azAZ";
 int val;
 val = (cast(int*)c.ptr)[0..1][0];
 //DEBUG
 //writef("(%02d)%08b",c[0],c[0]);
 //writef(",(%02d)%08b",c[1],c[1]);
 //writef(",(%02d)%08b",c[2],c[2]);
 //writefln(",(%02d)%08b",c[3],c[3]);
 writefln("%032b",val);
 val >>= 1;
 writefln("%032b",val);
 }

Thanks, this is what im looking for! But I don't understand this line:
 val = (cast(int*)c.ptr)[0..1][0];

What does [0..1][0] mean?
 p.s. nobody got the ascii values backward ('A' is 65, 'a' is 97)
 it's nobody's fault really.. nobody is to blame..
 
 "nobody" I love the nick.. have you read the "Deverry" novels by
 "Katherine Kerr"?
 http://www.math.ttu.edu/~kesinger/deverry/kerr.biblio.html

The oldest example of such pun I know of is Polyphemus who is fooled by this name in Homer's Odyssey which I read parts of in my Latin lessons at school (albeit the original is Greek). --> http://en.wikipedia.org/wiki/Polyphemus Peter
Aug 23 2006
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 24 Aug 2006 03:53:28 +0200, Peter Thomassen  
<info peter-thomassen.de> wrote:
 Regan Heath schrieb am Mittwoch, 23. August 2006 02:06:
 Depends what exactly you're trying to do, perhaps this:

 import std.stdio;

 void main()
 {
 char[] c = "azAZ";
 int val;
 val = (cast(int*)c.ptr)[0..1][0];
 //DEBUG
 //writef("(%02d)%08b",c[0],c[0]);
 //writef(",(%02d)%08b",c[1],c[1]);
 //writef(",(%02d)%08b",c[2],c[2]);
 //writefln(",(%02d)%08b",c[3],c[3]);
 writefln("%032b",val);
 val >>= 1;
 writefln("%032b",val);
 }

Thanks, this is what im looking for! But I don't understand this line:
 val = (cast(int*)c.ptr)[0..1][0];

What does [0..1][0] mean?

Ahh.. to understand the line we need to know that D allows us to slice pointers and the result is an array, lets break the line into steps. Step1: cast(int*)c.ptr, this tells it to pretend the pointer to the char[] data is an int pointer. Step2: [0..1], this requests a slice (AKA array) of the data referenced by the (now) int pointer. The result is an int[], in this case with only 1 item, a single int. Step3: [0] returns the first item (only item) in the int slice (array), an int. Because we're only after a single int, we can actually do it in a much simpler fashion, this: val = *(cast(int*)c.ptr); If you have a large block of char[] data to process you might use: char[] c = "the quick brown fox jumps over the lazy dog"; foreach(int val; cast(int[])c) { ..etc.. } or similar.
 p.s. nobody got the ascii values backward ('A' is 65, 'a' is 97)
 it's nobody's fault really.. nobody is to blame..

 "nobody" I love the nick.. have you read the "Deverry" novels by
 "Katherine Kerr"?
 http://www.math.ttu.edu/~kesinger/deverry/kerr.biblio.html

The oldest example of such pun I know of is Polyphemus who is fooled by this name in Homer's Odyssey which I read parts of in my Latin lessons at school (albeit the original is Greek). --> http://en.wikipedia.org/wiki/Polyphemus

Cool. Regan
Aug 23 2006
parent reply Peter Thomassen <info peter-thomassen.de> writes:
Regan Heath schrieb am Donnerstag, 24. August 2006 04:21:
 Thanks, this is what im looking for! But I don't understand this line:
 val = (cast(int*)c.ptr)[0..1][0];

What does [0..1][0] mean?

Ahh.. to understand the line we need to know that D allows us to slice pointers and the result is an array, lets break the line into steps. Step1: cast(int*)c.ptr, this tells it to pretend the pointer to the char[] data is an int pointer. Step2: [0..1], this requests a slice (AKA array) of the data referenced by the (now) int pointer. The result is an int[], in this case with only 1 item, a single int. Step3: [0] returns the first item (only item) in the int slice (array), an int.

Okay, nearly understood. But doesn't [0..1] produce two items, namely [0] and [1]? Peter
Aug 23 2006
parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Thu, 24 Aug 2006 04:33:53 +0200, Peter Thomassen wrote:

 
 Okay, nearly understood. But doesn't [0..1] produce two items, namely [0]
 and [1]?

The semantics of a slice specification is that the slice starts with the element indexed by the first index and extends to all the elements up to, but not including, the second index. Thus [0..1] means a slice containing element[0] only, and [4..7] means element[4], element[5], and element[6] is included in the slice, but not element[7]. To get all the elements except the last element we can use [0..$-1] -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocrity!" 24/08/2006 1:05:56 PM
Aug 23 2006
parent Peter Thomassen <info peter-thomassen.de> writes:
Derek Parnell schrieb am Donnerstag, 24. August 2006 05:06:
 Okay, nearly understood. But doesn't [0..1] produce two items, namely [0]
 and [1]?

The semantics of a slice specification is that the slice starts with the element indexed by the first index and extends to all the elements up to, but not including, the second index. Thus [0..1] means a slice containing element[0] only, and [4..7] means element[4], element[5], and element[6] is included in the slice, but not element[7]. To get all the elements except the last element we can use [0..$-1]

Thanks! Peter
Aug 24 2006
prev sibling parent Brad Roberts <braddr puremagic.com> writes:
On Fri, 25 Aug 2006, Chad J wrote:

 nobody wrote:
 Chad J wrote:
 
 nobody wrote:
 
 Chad J wrote:
 
 nobody wrote:
 ....
 
 
 So you will have to do it manually. I would like to suggest that if
 you can pad the char[] to ensure its .length % 8 == 0 then you can
 cast it to a ulong and your shifting will be faster.

Sure about ulong? In my spare time I made my own minimal Bignum implementation. I'm not sure about shifts, but for addition with carrying it was faster to use size_t (uint in this case) rather than ulong. I wonder if maybe the compiler could optimize it better if it didn't have to emulate 64 bit integers. Or my benchmark was borked.

I certainly could be wrong but I would be quite surprised. I would be interested to see what tests you ran that suggest addition with carry was faster.

This BigNum I made is very incomplete and probably slow. Changing the size of it's digits shouldn't do anything besides just that, though. I have attached 2 .d files, BigNum.d is the implementation, main.d is the benchmark. I compiled it with dmd -O -inline -release. At the top of BigNum.d there is an alias that I use to switch between size_t and ulong variables used in the computation. Here are my results. See main.d for details of the setup. Microseconds to complete 1000000 additions using size_t: 786779 776801 793653 783896 787937 789150 Microseconds to complete 1000000 additions using ulong: 866767 860499 866921 865791 860874 858154

Thanks for taking the time to post this. It will be a little while before I can sit down and play with the code you sent so I thought I would give you my first impression. It looks like you have tested the time it takes to add a 20 "digit" number to an 18 "digit" number: BigDigit[20] test1; BigDigit[18] test2; You define these numbers as one of the two: alias size_t BigDigit; // for optimal performance alias ulong BigDigit; I think the easiest way to suggest the problem with your test is in finding how many bytes we are adding in each case: 20 * 4 = 80 bytes 20 * 8 = 160 bytes What your results actually seem to be saying is that treating char[160] as a ulong takes slightly longer than treating char[80] as a uint. I am still fairly convinced that if you test again with an equal number of bytes you should find that the ulong case will be faster. If you have a chance to run the test before me I would be interested to hear the results.

Ah, good catch. That does turn the results around, now the ulong leads slightly instead of the other way around. Changed BigDigit[20] test1; BigDigit[18] test2; to ulong[20] test1; ulong[18] test2; w/ size_t: 880821 905326 871996 895222 897846 w/ ulong: 849123 848298 849372 852560 895887 Another thing with the test... random numbers. It probably won't matter much, but when using 64 bit digits, only the lo 32 bits get filled by phobo's rand() function, which means no carrying, ever. Also, it might be interesting to do extreme cases like where the numbers always have all of the bits set, which forces carrying all the time. I also noticed that I broke the unittest when I tried to free up any memory the carrying might have wasted, so I've fixed that and here's the new version. (This really didn't have an effect on speed, just correctness)

Have any of you looked at the GMP library? It's a highly optimized large number library. It supports both large integers and large floats. Providing a D wrapper on top of it would be the direction I'd head in for this sort of use case. Later, Brad
Aug 25 2006
prev sibling parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
Do you want the numeric (integer/float) value of the string in a char[]?

For example, "1.0" => 1.0, and similar?

In other words, something similar to:

$x = (int) '324';
$y = intval('562');
$z = '324' + '9';

In PHP?  If so, you want std.conv.  The D code might look like this:

x = toInt(324);
y = toInt(562);
z = toInt(324) + toInt(9);

There's also toFloat, toDouble, toUint, etc.  See:

http://digitalmars.com/d/phobos/std_conv.html

Please note that an Exception is thrown if it cannot be converted, it 
won't just be made 0.  So, for example:

try
	x = toInt(user_value);
catch (ConvError)
	x = 0;
catch (ConvOverflowError)
	x = int.max;

Or something like that.

If that's not what you want, a char[] is actually two numeric values - 
much like in PHP.  It is a length value, and a pointer.  Bit shifting 
these probably won't give you anything interesting.

-[Unknown]


 Hi,
 
 how is it possible to work on the numeric value of a char[]? I'm interested
 in bit shifting and arithmetic operations on the numeric value.
 
 Thanks!
 Peter

Aug 22 2006