Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #25064 > unrolled thread

Autoboxing and Performance ?

Back to article view | Back to comp.lang.java.programmer

Contents

  Autoboxing and Performance ? Peter Olcott <OCR4Screen> - 2013-08-20 05:15 -0500
    Re: Autoboxing and Performance ? Joerg Meier <joergmmeier@arcor.de> - 2013-08-20 12:20 +0200
      Re: Autoboxing and Performance ? Peter Olcott <OCR4Screen> - 2013-08-20 05:33 -0500
        Re: Autoboxing and Performance ? Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-08-20 10:43 +0000
          Re: Autoboxing and Performance ? Peter Olcott <OCR4Screen> - 2013-08-20 06:04 -0500
            Re: Autoboxing and Performance ? Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-08-20 08:08 -0400
            Re: Autoboxing and Performance ? Arne Vajhøj <arne@vajhoej.dk> - 2013-08-20 20:15 -0400
        Re: Autoboxing and Performance ? Arne Vajhøj <arne@vajhoej.dk> - 2013-08-20 20:12 -0400
        Re: Autoboxing and Performance ? Sven Köhler <remove-sven.koehler@gmail.com> - 2013-08-21 03:52 +0300
          Re: Autoboxing and Performance ? Sebastian <news@seyweiler.dyndns.org> - 2013-08-21 07:27 +0200
            Re: Autoboxing and Performance ? Arne Vajhøj <arne@vajhoej.dk> - 2013-08-21 18:43 -0400
              Re: Autoboxing and Performance ? Sven Köhler <remove-sven.koehler@gmail.com> - 2013-08-22 08:08 +0300
            Re: Autoboxing and Performance ? Sven Köhler <remove-sven.koehler@gmail.com> - 2013-08-22 07:56 +0300
              Re: Autoboxing and Performance ? Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-08-22 10:51 -0700
                Re: Autoboxing and Performance ? Martin Gregorie <martin@address-in-sig.invalid> - 2013-08-22 19:36 +0000
                  Re: Autoboxing and Performance ? Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-08-22 13:01 -0700
                  Re: Autoboxing and Performance ? Martin Gregorie <martin@address-in-sig.invalid> - 2013-08-22 21:19 +0000
                    Re: Autoboxing and Performance ? Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-08-22 14:39 -0700
                      Re: Autoboxing and Performance ? markspace <markspace@nospam.nospam> - 2013-08-22 19:50 -0700
                        Re: Autoboxing and Performance ? Martin Gregorie <martin@address-in-sig.invalid> - 2013-08-23 23:16 +0000
                          Re: Autoboxing and Performance ? Sven Köhler <remove-sven.koehler@gmail.com> - 2013-08-24 17:20 +0300
                    Re: Autoboxing and Performance ? Lew <lewbloch@gmail.com> - 2013-08-23 11:08 -0700
                      Re: Autoboxing and Performance ? Joerg Meier <joergmmeier@arcor.de> - 2013-08-23 22:52 +0200
                        Re: Autoboxing and Performance ? Jim Gibson <jimsgibson@gmail.com> - 2013-08-23 16:38 -0700
                  Re: Autoboxing and Performance ? "John B. Matthews" <nospam@nospam.invalid> - 2013-08-23 06:17 -0400
                    Re: Autoboxing and Performance ? Jeff Higgins <jeff@invalid.invalid> - 2013-08-23 17:25 -0400
                    Re: Autoboxing and Performance ? Jeff Higgins <jeff@invalid.invalid> - 2013-08-25 18:34 -0400
                      Re: Autoboxing and Performance ? Jeff Higgins <jeff@invalid.invalid> - 2013-08-28 10:52 -0400
                  Re: Autoboxing and Performance ? Martin Gregorie <martin@address-in-sig.invalid> - 2013-08-23 23:37 +0000
          Re: Autoboxing and Performance ? Robert Klemme <shortcutter@googlemail.com> - 2013-08-26 19:33 +0200
            Re: Autoboxing and Performance ? Sven Köhler <remove-sven.koehler@gmail.com> - 2013-08-29 10:09 +0300
              Re: Autoboxing and Performance ? Jan Burse <janburse@fastmail.fm> - 2013-08-29 14:14 +0200
        Re: Autoboxing and Performance ? Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-08-29 21:28 -0300
    Re: Autoboxing and Performance ? Jan Burse <janburse@fastmail.fm> - 2013-08-20 20:03 +0200
      Re: Autoboxing and Performance ? Lew <lewbloch@gmail.com> - 2013-08-20 16:23 -0700
        Re: Autoboxing and Performance ? Jan Burse <janburse@fastmail.fm> - 2013-08-21 11:51 +0200
          Re: Autoboxing and Performance ? Lew <lewbloch@gmail.com> - 2013-08-21 08:39 -0700
            Re: Autoboxing and Performance ? lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-08-21 16:51 +0100
          Re: Autoboxing and Performance ? Arne Vajhøj <arne@vajhoej.dk> - 2013-08-21 19:19 -0400
            Re: Autoboxing and Performance ? Jan Burse <janburse@fastmail.fm> - 2013-08-22 09:49 +0200
      Re: Autoboxing and Performance ? Jan Burse <janburse@fastmail.fm> - 2013-08-21 11:54 +0200
    Re: Autoboxing and Performance ? Arne Vajhøj <arne@vajhoej.dk> - 2013-08-20 20:06 -0400
      Re: Autoboxing and Performance ? Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-08-20 21:19 -0400
        Re: Autoboxing and Performance ? Joerg Meier <joergmmeier@arcor.de> - 2013-08-21 10:05 +0200
          Re: Autoboxing and Performance ? Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-08-21 07:19 -0400
            Re: Autoboxing and Performance ? Joerg Meier <joergmmeier@arcor.de> - 2013-08-22 00:18 +0200
              Re: Autoboxing and Performance ? Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-08-21 19:58 -0400
          Re: Autoboxing and Performance ? Lew <lewbloch@gmail.com> - 2013-08-21 08:36 -0700
        Re: Autoboxing and Performance ? taqmcg@gmail.com - 2013-08-21 09:37 -0700
    Re: Autoboxing and Performance ? Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2013-08-20 23:28 -0500
    Re: Autoboxing and Performance ? lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-08-21 10:09 +0100
      Re: Autoboxing and Performance ? Arne Vajhøj <arne@vajhoej.dk> - 2013-08-21 19:04 -0400
        Re: Autoboxing and Performance ? Arivald <NOSPAMarivald@interia.pl> - 2013-08-22 07:39 +0200
    Re: Autoboxing and Performance ? Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-08-29 01:42 -0300

Page 1 of 3  [1] 2 3  Next page →

#25064 — Autoboxing and Performance ?

 From Java A Beginner's Guide, Fifth Edition by Herbert Schildt, page 425:

class AutoBox3 {
   public static void main(String args[]) {
   Integer iOb;
   iOb = 99;

// The following automatically unboxes iOb,
// performs the increment, and then reboxes
// the result back into iOb
++iOb;

It seems to me that all this unboxing and reboxing is a complete waste 
of CPU time. It would make much more sense to provide an 
Integer.Increment() member function that directly operates on the 
contained data.

Why does Java waste so much CPU resources with its unboxing and reboxing 
in cases such as this, and not simply provide member functions that 
directly operate on the contained data?

[toc] | [next] | [standalone]

#25065

On Tue, 20 Aug 2013 05:15:30 -0500, Peter Olcott wrote:

>  From Java A Beginner's Guide, Fifth Edition by Herbert Schildt, page 425:

> class AutoBox3 {
>    public static void main(String args[]) {
>    Integer iOb;
>    iOb = 99;

> // The following automatically unboxes iOb,
> // performs the increment, and then reboxes
> // the result back into iOb
> ++iOb;

> It seems to me that all this unboxing and reboxing is a complete waste 
> of CPU time. It would make much more sense to provide an 
> Integer.Increment() member function that directly operates on the 
> contained data.

> Why does Java waste so much CPU resources with its unboxing and reboxing 
> in cases such as this, and not simply provide member functions that 
> directly operate on the contained data?

Because IntegerS and other Number classes are immutable. The contained data
is not allowed to be changed under any circumstances.

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[toc] | [prev] | [next] | [standalone]

#25066

On 8/20/2013 5:20 AM, Joerg Meier wrote:
> On Tue, 20 Aug 2013 05:15:30 -0500, Peter Olcott wrote:
>
>>   From Java A Beginner's Guide, Fifth Edition by Herbert Schildt, page 425:
>
>> class AutoBox3 {
>>     public static void main(String args[]) {
>>     Integer iOb;
>>     iOb = 99;
>
>> // The following automatically unboxes iOb,
>> // performs the increment, and then reboxes
>> // the result back into iOb
>> ++iOb;
>
>> It seems to me that all this unboxing and reboxing is a complete waste
>> of CPU time. It would make much more sense to provide an
>> Integer.Increment() member function that directly operates on the
>> contained data.
>
>> Why does Java waste so much CPU resources with its unboxing and reboxing
>> in cases such as this, and not simply provide member functions that
>> directly operate on the contained data?
>
> Because IntegerS and other Number classes are immutable. The contained data
> is not allowed to be changed under any circumstances.
>
> Liebe Gruesse,
> 		Joerg
>

So the original object is replaced with a new object?

What is the benefit (of immutability) that is worth the cost of this 
poor performance?

[toc] | [prev] | [next] | [standalone]

#25067

Peter Olcott <OCR4Screen> wrote:
> On 8/20/2013 5:20 AM, Joerg Meier wrote:
>> On Tue, 20 Aug 2013 05:15:30 -0500, Peter Olcott wrote:
>>
>>>   From Java A Beginner's Guide, Fifth Edition by Herbert Schildt, page 425:
>>
>>> class AutoBox3 {
>>>     public static void main(String args[]) {
>>>     Integer iOb;
>>>     iOb = 99;
>>
>>> // The following automatically unboxes iOb,
>>> // performs the increment, and then reboxes
>>> // the result back into iOb
>>> ++iOb;
>>
>>> It seems to me that all this unboxing and reboxing is a complete waste
>>> of CPU time. It would make much more sense to provide an
>>> Integer.Increment() member function that directly operates on the
>>> contained data.
>>
>>> Why does Java waste so much CPU resources with its unboxing and reboxing
>>> in cases such as this, and not simply provide member functions that
>>> directly operate on the contained data?
>>
>> Because IntegerS and other Number classes are immutable. The contained data
>> is not allowed to be changed under any circumstances.
>>
>> Liebe Gruesse,
>> 		Joerg
>>
>
> So the original object is replaced with a new object?
>
> What is the benefit (of immutability) that is worth the cost of this 
> poor performance?

The lesson probably should be, that if you intend to do math on 
a variable, that you should use the primitive types instead.

 class NoAutoBox {
     public static void main(String args[]) {
        int iOb;
        iOb = 99;
        ++iOb; // value is overwritten; no objects created.
     }
 }

PS: doing math on them is not the only use for integral numeric types.

[toc] | [prev] | [next] | [standalone]

#25068

On 8/20/2013 5:43 AM, Andreas Leitgeb wrote:
> Peter Olcott <OCR4Screen> wrote:
>> On 8/20/2013 5:20 AM, Joerg Meier wrote:
>>> On Tue, 20 Aug 2013 05:15:30 -0500, Peter Olcott wrote:
>>>
>>>>    From Java A Beginner's Guide, Fifth Edition by Herbert Schildt, page 425:
>>>
>>>> class AutoBox3 {
>>>>      public static void main(String args[]) {
>>>>      Integer iOb;
>>>>      iOb = 99;
>>>
>>>> // The following automatically unboxes iOb,
>>>> // performs the increment, and then reboxes
>>>> // the result back into iOb
>>>> ++iOb;
>>>
>>>> It seems to me that all this unboxing and reboxing is a complete waste
>>>> of CPU time. It would make much more sense to provide an
>>>> Integer.Increment() member function that directly operates on the
>>>> contained data.
>>>
>>>> Why does Java waste so much CPU resources with its unboxing and reboxing
>>>> in cases such as this, and not simply provide member functions that
>>>> directly operate on the contained data?
>>>
>>> Because IntegerS and other Number classes are immutable. The contained data
>>> is not allowed to be changed under any circumstances.
>>>
>>> Liebe Gruesse,
>>> 		Joerg
>>>
>>
>> So the original object is replaced with a new object?
>>
>> What is the benefit (of immutability) that is worth the cost of this
>> poor performance?
>
> The lesson probably should be, that if you intend to do math on
> a variable, that you should use the primitive types instead.
>
>   class NoAutoBox {
>       public static void main(String args[]) {
>          int iOb;
>          iOb = 99;
>          ++iOb; // value is overwritten; no objects created.
>       }
>   }
>
> PS: doing math on them is not the only use for integral numeric types.
>

I am trying to understand the Java language design principles that are 
underlying the reasoning why there is such a thing as unboxing and 
reboxing. I can see why class objects should be kept in a box, no 
unboxing or reboxing required.

I do not see why primitive objects must be kept in a box, or why they 
must be unboxed and reboxed if they are to be operated upon.

[toc] | [prev] | [next] | [standalone]

#25069

On 8/20/2013 7:04 AM, Peter Olcott wrote:
> On 8/20/2013 5:43 AM, Andreas Leitgeb wrote:
>> Peter Olcott <OCR4Screen> wrote:
>>> On 8/20/2013 5:20 AM, Joerg Meier wrote:
>>>> On Tue, 20 Aug 2013 05:15:30 -0500, Peter Olcott wrote:
>>>>
>>>>>    From Java A Beginner's Guide, Fifth Edition by Herbert Schildt,
>>>>> page 425:
>>>>
>>>>> class AutoBox3 {
>>>>>      public static void main(String args[]) {
>>>>>      Integer iOb;
>>>>>      iOb = 99;
>>>>
>>>>> // The following automatically unboxes iOb,
>>>>> // performs the increment, and then reboxes
>>>>> // the result back into iOb
>>>>> ++iOb;
>>>>
>>>>> It seems to me that all this unboxing and reboxing is a complete waste
>>>>> of CPU time. It would make much more sense to provide an
>>>>> Integer.Increment() member function that directly operates on the
>>>>> contained data.
>>>>
>>>>> Why does Java waste so much CPU resources with its unboxing and
>>>>> reboxing
>>>>> in cases such as this, and not simply provide member functions that
>>>>> directly operate on the contained data?
>>>>
>>>> Because IntegerS and other Number classes are immutable. The
>>>> contained data
>>>> is not allowed to be changed under any circumstances.
>>>>
>>>> Liebe Gruesse,
>>>>         Joerg
>>>>
>>>
>>> So the original object is replaced with a new object?
>>>
>>> What is the benefit (of immutability) that is worth the cost of this
>>> poor performance?
>>
>> The lesson probably should be, that if you intend to do math on
>> a variable, that you should use the primitive types instead.
>>
>>   class NoAutoBox {
>>       public static void main(String args[]) {
>>          int iOb;
>>          iOb = 99;
>>          ++iOb; // value is overwritten; no objects created.
>>       }
>>   }
>>
>> PS: doing math on them is not the only use for integral numeric types.
>>
>
> I am trying to understand the Java language design principles that are
> underlying the reasoning why there is such a thing as unboxing and
> reboxing. I can see why class objects should be kept in a box, no
> unboxing or reboxing required.
>
> I do not see why primitive objects must be kept in a box, or why they
> must be unboxed and reboxed if they are to be operated upon.

     There's no "must," there's a "may."

     At a low level Java cannot do arithmetic with Integer (or
Long or ...) objects, but only with int (long, ...) primitive
values.  And in the early days this was explicit: In order to
perform the increment in your example, you had to write

	Integer iOb = Integer.valueOf(99);
	iOb = Integer.valueOf(iOb.intValue() + 1);

... or something in that vein.  Boxing and unboxing just amount
to the compiler writing the boiler-plate for you; the same stuff
is still going on behind the scenes.

     So, why have Integer (Long, ...) objects in the first place?
Because there are contexts where you *must* have an object instance,
and a primitive value will not do.  For example, an ArrayList cannot
hold primitives, only object references.  The keys and values in a
HashMap cannot be primitives, only object references.  You cannot
synchronize on a primitive value, you cannot set a primitive to
`null', you cannot apply the `instanceof' operator to a primitive,
and the list goes on.  That's what Integer and its pals are for:
When you you want to use a value in a context that needs an object.

     IMHO boxing and unboxing are snares of Satan, creating more
confusion (e.g., this thread!) and trouble than they're worth.
The deeper problem, it seems to me, is that Java is unable to treat
a primitive the same way it treats an object: Why *shouldn't* you
be able to put 3.14159 in an ArrayList, or ask whether it is an
`instanceof short'?  However, the primitive-vs-reference chasm is
a deep divide in the design of Java, and there seems little chance
that it could ever go away.  Boxing and unboxing bridge the chasm,
but the bridge is rickety and you should tread it with care.

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#25078

On 8/20/2013 7:04 AM, Peter Olcott wrote:
> On 8/20/2013 5:43 AM, Andreas Leitgeb wrote:
>> Peter Olcott <OCR4Screen> wrote:
>>> On 8/20/2013 5:20 AM, Joerg Meier wrote:
>>>> On Tue, 20 Aug 2013 05:15:30 -0500, Peter Olcott wrote:
>>>>
>>>>>    From Java A Beginner's Guide, Fifth Edition by Herbert Schildt,
>>>>> page 425:
>>>>
>>>>> class AutoBox3 {
>>>>>      public static void main(String args[]) {
>>>>>      Integer iOb;
>>>>>      iOb = 99;
>>>>
>>>>> // The following automatically unboxes iOb,
>>>>> // performs the increment, and then reboxes
>>>>> // the result back into iOb
>>>>> ++iOb;
>>>>
>>>>> It seems to me that all this unboxing and reboxing is a complete waste
>>>>> of CPU time. It would make much more sense to provide an
>>>>> Integer.Increment() member function that directly operates on the
>>>>> contained data.
>>>>
>>>>> Why does Java waste so much CPU resources with its unboxing and
>>>>> reboxing
>>>>> in cases such as this, and not simply provide member functions that
>>>>> directly operate on the contained data?
>>>>
>>>> Because IntegerS and other Number classes are immutable. The
>>>> contained data
>>>> is not allowed to be changed under any circumstances.
>>>>
>>>> Liebe Gruesse,
>>>>         Joerg
>>>>
>>>
>>> So the original object is replaced with a new object?
>>>
>>> What is the benefit (of immutability) that is worth the cost of this
>>> poor performance?
>>
>> The lesson probably should be, that if you intend to do math on
>> a variable, that you should use the primitive types instead.
>>
>>   class NoAutoBox {
>>       public static void main(String args[]) {
>>          int iOb;
>>          iOb = 99;
>>          ++iOb; // value is overwritten; no objects created.
>>       }
>>   }
>>
>> PS: doing math on them is not the only use for integral numeric types.
>>
>
> I am trying to understand the Java language design principles that are
> underlying the reasoning why there is such a thing as unboxing and
> reboxing. I can see why class objects should be kept in a box, no
> unboxing or reboxing required.
>
> I do not see why primitive objects must be kept in a box, or why they
> must be unboxed and reboxed if they are to be operated upon.

Typical you would not keep integers etc. as boxed.

You may need to in some case (assign to Object, allow null etc.).

If you do then the immutability characteristics requires you to
unbox and box.

Arne

[toc] | [prev] | [next] | [standalone]

#25077

On 8/20/2013 6:33 AM, Peter Olcott wrote:
> On 8/20/2013 5:20 AM, Joerg Meier wrote:
>> On Tue, 20 Aug 2013 05:15:30 -0500, Peter Olcott wrote:
>>
>>>   From Java A Beginner's Guide, Fifth Edition by Herbert Schildt,
>>> page 425:
>>
>>> class AutoBox3 {
>>>     public static void main(String args[]) {
>>>     Integer iOb;
>>>     iOb = 99;
>>
>>> // The following automatically unboxes iOb,
>>> // performs the increment, and then reboxes
>>> // the result back into iOb
>>> ++iOb;
>>
>>> It seems to me that all this unboxing and reboxing is a complete waste
>>> of CPU time. It would make much more sense to provide an
>>> Integer.Increment() member function that directly operates on the
>>> contained data.
>>
>>> Why does Java waste so much CPU resources with its unboxing and reboxing
>>> in cases such as this, and not simply provide member functions that
>>> directly operate on the contained data?
>>
>> Because IntegerS and other Number classes are immutable. The contained
>> data
>> is not allowed to be changed under any circumstances.
>
> So the original object is replaced with a new object?

Yes.

> What is the benefit (of immutability) that is worth the cost of this
> poor performance?

Immutability allows for certain optimizations especially
in multithreaded contexts.

And you do not get the poor performance, because you switch to
simple data types when you need to do a lot of these operations.

Of course you need to know that. Maybe that is what the author
tries to communicate.

Arne

[toc] | [prev] | [next] | [standalone]

#25080

Am 20.08.2013 13:33, schrieb Peter Olcott:
> What is the benefit (of immutability) that is worth the cost of this
> poor performance?

Well, if you have a mutable object, programming becomes a bit of a pain,
doesn't it? You just checked whether the integer is in a certain range,
and asynchronously the value of that variables is changed by another
thread. Also, what if you used the Integer object as a key in a hashmap?
The hashmap would become inconsistent if the value of that Integer
object changes.

That said, I seriously think that all the wrapper classes were just
intended for what the name suggests: wrapping a primitive type when you
really need an Object. And most of the time you don't need an object.
I'd even call program is seriously broken if it uses Integer where int
could be used. I was never in need of a mutable Integer.


Regards,
  Sven

[toc] | [prev] | [next] | [standalone]

#25084

Am 21.08.2013 02:52, schrieb Sven Köhler:
> Am 20.08.2013 13:33, schrieb Peter Olcott:
>> What is the benefit (of immutability) that is worth the cost of this
>> poor performance?
>
[snip]
>
> That said, I seriously think that all the wrapper classes were just
> intended for what the name suggests: wrapping a primitive type when you
> really need an Object. And most of the time you don't need an object.
> I'd even call program is seriously broken if it uses Integer where int
> could be used. I was never in need of a mutable Integer.
>
>
> Regards,
>    Sven

Apart from the issue of mutability (which does not arise in Java int or
Integer), I sometimes use Integer when I want to have a special value
for "not set", namely "null". With int, it is necessary to reserve some
arbitrary value for that purpose (like -1 when the range is positive, or
perhaps Integer.MIN_VALUE otherwise). And one needs to publish a
constant for that value if other code needs to check whether the value
is present, making it well nigh impossible to change the implementation
later.

What do you think? Is simply wanting to have a "null" value a valid
reason for using Integer instead of int?

-- Sebastian

[toc] | [prev] | [next] | [standalone]

#25097

On 8/21/2013 1:27 AM, Sebastian wrote:
> Am 21.08.2013 02:52, schrieb Sven Köhler:
>> Am 20.08.2013 13:33, schrieb Peter Olcott:
>>> What is the benefit (of immutability) that is worth the cost of this
>>> poor performance?
>>
> [snip]
>>
>> That said, I seriously think that all the wrapper classes were just
>> intended for what the name suggests: wrapping a primitive type when you
>> really need an Object. And most of the time you don't need an object.
>> I'd even call program is seriously broken if it uses Integer where int
>> could be used. I was never in need of a mutable Integer.

> Apart from the issue of mutability (which does not arise in Java int or
> Integer), I sometimes use Integer when I want to have a special value
> for "not set", namely "null". With int, it is necessary to reserve some
> arbitrary value for that purpose (like -1 when the range is positive, or
> perhaps Integer.MIN_VALUE otherwise). And one needs to publish a
> constant for that value if other code needs to check whether the value
> is present, making it well nigh impossible to change the implementation
> later.
>
> What do you think? Is simply wanting to have a "null" value a valid
> reason for using Integer instead of int?

Yes.

And C# that was born with int as an object and therefore did
not get wrapper classes later had to add int? to get a
nullable int.

Arne

[toc] | [prev] | [next] | [standalone]

#25102

Am 22.08.2013 01:43, schrieb Arne Vajhøj:
> And C# that was born with int as an object and therefore did
> not get wrapper classes later had to add int? to get a
> nullable int.

So C# distinguishes between int and int? - the former being non-nullable
and the latter being nullable.

I can easily subscribe to the point of view, that C# does everything
such that the programmer is provided with the illusion that a variable
of type int is actually an object. However, I wonder whether converting
int to int? and back again might not be implemented using some form of
boxing and unboxing - maybe even with a comparable performance hit.
Certainly, the (un)boxing can be optimized away in some cases - but not
all of them.


Regards,
  Sven

[toc] | [prev] | [next] | [standalone]

#25101

Am 21.08.2013 08:27, schrieb Sebastian:
> What do you think? Is simply wanting to have a "null" value a valid
> reason for using Integer instead of int?

If you just store the value like that, that is probably just fine.
However, if I see your program actually working with that nullable int
and thus unboxing/reboxing it over and over again, then that should
probably be criticized if the code path is performance critical.
Also, it is a fact that having hundreds and thousands of Integer objects
take probably 4 times more space than having the same number of ints.

I guess, I'd rather not like to settle on a general yes/no - it depends.


Regards,
  Sven

[toc] | [prev] | [next] | [standalone]

#25108

On 8/21/13 9:56 PM, Sven Köhler wrote:
> Am 21.08.2013 08:27, schrieb Sebastian:
>> What do you think? Is simply wanting to have a "null" value a valid
>> reason for using Integer instead of int?
>
> If you just store the value like that, that is probably just fine.
> However, if I see your program actually working with that nullable int
> and thus unboxing/reboxing it over and over again, then that should
> probably be criticized if the code path is performance critical.
> Also, it is a fact that having hundreds and thousands of Integer objects
> take probably 4 times more space than having the same number of ints.
It depends.  There is a small "cache" of objects that will reused.

> I guess, I'd rather not like to settle on a general yes/no - it depends.

Good OO design would say that you shouldn't have many "raw" values, 
primitive or otherwise. Most numeric values represent something 
specific, so you should create a class to describe that specific 
something.  Whether that class has an immutable value or not depends on 
what makes sense for the context.

Start with a clean and clear design. If you find that too many resources 
are being used, then and only then reduce to use raw primitives.

To be clear, I'm not talking about "int" vs "Integer". Those are both 
Primitive (though not primitive).  I'm talking about "int" vs "Length".

Same goes for collections. A "List" or even an array are relatively 
primitive, and in many circumstances should be wrapped.  Not all, of 
course, but if the List object is passed around, then it may be better 
to replace it with an abstraction.

Granted, this is all from a purist OO design, and in reality adding 
these abstractions may produce bulky code which is actually less clear. 
Only experience can help in determining when to and when not to.

[toc] | [prev] | [next] | [standalone]

#25110

On Thu, 22 Aug 2013 10:51:00 -0700, Daniel Pitts wrote:

> To be clear, I'm not talking about "int" vs "Integer". Those are both
> Primitive (though not primitive).  I'm talking about "int" vs "Length".
>
Not a particularly good example, if I might say so, because a Length 
should always have a units attribute and so is neither primitive nor 
Primitive. AtomicNumber or AtomicWeight would be better examples since 
both are dimensionless numbers.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#25112

On 8/22/13 12:36 PM, Martin Gregorie wrote:
> On Thu, 22 Aug 2013 10:51:00 -0700, Daniel Pitts wrote:
>
>> To be clear, I'm not talking about "int" vs "Integer". Those are both
>> Primitive (though not primitive).  I'm talking about "int" vs "Length".
>>
> Not a particularly good example, if I might say so, because a Length
> should always have a units attribute and so is neither primitive nor
> Primitive. AtomicNumber or AtomicWeight would be better examples since
> both are dimensionless numbers.
>
>
That's part of my point, actually. Length might store it as an "int", 
but it would be "int inches" or "int millimeters", then it would have 
getters/setters to handle the proper unit conversions.

Unfortunately, people tend to do this instead:

int length; // length in cm.

or even just:

int length;

[toc] | [prev] | [next] | [standalone]

#25114

On Thu, 22 Aug 2013 20:19:58 +0000, Stefan Ram wrote:

>   Moreover, a lenght (in physics) /does not have/ a unit!
>
As a chemistry graduate I disagree quite strongly with that. Its quite 
impossible to calculate anything without knowing the units the givens 
were measured in. I seem to recall a certain NASA Mars probe failing 
because the units used to measure fuel remaining were unstated. As a 
result somebody calculated burns wrongly by confusing lbs and kg, causing 
the probe to run out of fuel and miss Mars entirely.

>   For example, there is a certain distance from the sun to the Procyon,
>   what is the unit of that lenght? As a physical value, it has no unit!
>   Only when one wants to write it down, one has to choose a certain unit
>   system and number system, and one can choose every unit system one
>   likes. This is an artefact of our notation, not a property of the
>   length.
>
If you don't know the units the measurement was made in, its a 
meaningless number that can't be used to calculate a valid result any 
more than you can add "not very far" to "a huge distance" and get a 
measurable distance.
 

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#25115

On 8/22/13 2:19 PM, Martin Gregorie wrote:
> On Thu, 22 Aug 2013 20:19:58 +0000, Stefan Ram wrote:
>
>>    Moreover, a lenght (in physics) /does not have/ a unit!
>>
> As a chemistry graduate I disagree quite strongly with that. Its quite
> impossible to calculate anything without knowing the units the givens
> were measured in. I seem to recall a certain NASA Mars probe failing
> because the units used to measure fuel remaining were unstated. As a
> result somebody calculated burns wrongly by confusing lbs and kg, causing
> the probe to run out of fuel and miss Mars entirely.
>
>>    For example, there is a certain distance from the sun to the Procyon,
>>    what is the unit of that lenght? As a physical value, it has no unit!
>>    Only when one wants to write it down, one has to choose a certain unit
>>    system and number system, and one can choose every unit system one
>>    likes. This is an artefact of our notation, not a property of the
>>    length.
>>
> If you don't know the units the measurement was made in, its a
> meaningless number that can't be used to calculate a valid result any
> more than you can add "not very far" to "a huge distance" and get a
> measurable distance.
>
>
To Stefan's point, the distance itself isn't actually a number with a 
unit. It isn't a number at all but a concrete distance.  To *represent* 
that distance, you need to know two things about it, a number and a 
unit.   Unit's themselves are concrete values, which can be multiplied 
by a scalar to arrive at other concrete values.

In other words, to measure something, you compare it to multiples of 
some other something. The number of multiples is your scalar, and the 
"some other something" is the unit.

So, the unit needn't be recorded along with the number, as long as the 
unit and number are tied together somehow.  A Length class is the 
perfect place to do that tying. A Length class can store the value as a 
number, and ensure that the units consistent. The units may be implicit 
or explicit. Implicit units meaning the Length class always uses the 
same units to store the value, and only converts when asked for 
different units. Explicit units means the Length class stores a Unit 
property, which handles the conversion.

[toc] | [prev] | [next] | [standalone]

#25119

On 8/22/2013 2:48 PM, Stefan Ram wrote:
> Daniel Pitts <newsgroup.nospam@virtualinfinity.net> writes:
>> To *represent* that distance, you need to know two things
>> about it, a number and a unit.
>
>    In numeric calculations, but not in symbolic calculations,
>    both of which are done by computers today.
>


Hmm, ok.  Symbolic means speed = distance / time.  No units involved there.

But to calculate a speed, the computer does indeed need the units involved.

Works for me.

[toc] | [prev] | [next] | [standalone]

#25129

On Fri, 23 Aug 2013 04:41:45 +0000, Stefan Ram wrote:

> markspace <markspace@nospam.nospam> writes:
>>Hmm, ok.  Symbolic means speed = distance / time.  No units involved
>>there.
> 
>   For example, when an object initially rests at height h,
>   we want to known its terminal speed v upon impact.
>   The potential energy is mgh, so mgh=½mv², thus v = sqrt(2gh).
>   Thus, we have symbolically calculated the impact speed v.
> 
>   Computer Software also can do such calculations after it has learned
>   the assertions to start from, such as mgh=½mv², and been told to which
>   variable to solve this for. The symbolic result of the software will
>   be: »v=sqrt(2gh)«.
>
In my book that's algebraic manipulation, i.e. mathematics, not physics. 
Physics purports to describe the real world and hence any measurement 
must specify the units, while algebra is dimensionless.



-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web