Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (483)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (550)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 ... 5 6 [7] 8 9 10
  ignore  |  Print  
  Things you disagree with in the java language  (Read 38857 times)
0 Members and 1 Guest are viewing this topic.
Offline pjt33
« Reply #180 - Posted 2012-09-08 19:11:03 »

Someone commented on one type of programming language feature involving a theological argument, but I think everything here can be debated on its merits.
The "religious war" aspect comes because people have different weightings for the same merits.
Offline Spasi
« Reply #181 - Posted 2012-09-08 19:16:25 »

I've configured my IDE to highlight @Nullable issues as errors and it's quite surprising how much code is affected when you annotate something with it. Like Riven said, it's similar to how generics code propagates. I agree that NPEs are relatively easy to solve, but not always. I find that @Nullable considerably reduces how much time I spend hunting down NPEs and also forces me to think twice about when and where I use nullable fields/arguments/return values. It's often better to refactor code and use more immutable classes.

What bit pattern would you use to represent null primitives? Raw data shouldn't be nullable because it forces you to add a layer of indirection or restrictions. I'm a little confused about what the merits of non-nullable types would be. Would full support for contracts or having the ability to use compile time asserts accomplish the same thing? I can imagine something like kotlin's safe casts thing, but don't know why you would stop at null references or if that would even have a good return on investment on its own. They're not a major problem. Maybe requiring all fields to be initialized the same way final fields and local variables are would also be along the same line by saying "It doesn't make sense to give this a default value, null or not. You need to explicitly initialize it to something."

In Kotlin, nullable primitives compile down to the corresponding wrapper class. Example:

1  
2  
val a: Int = 1 // primitive
val b: Int? = 1 // java.lang.Integer


Except references, Kotlin allows you to specify nullability to array/collection parameters as well. That's where it gets interesting and really useful:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
val foo = array("a", "b", "c") // type is Array<String>
val bar = array("d", null, "f") // type is Array<String?>

println(foo[0].length) // works
println(bar[0].length) // compile-time error
println(bar[0]?.length) // works, the expression type is Int?

val s = bar[0] // type is String?
if ( s != null )
   println(s.length) // works with auto-cast from String? to String
Offline Best Username Ever

Junior Member





« Reply #182 - Posted 2012-09-08 20:43:09 »

@pjt33 Makes sense, but that's the main reason why I think multiple languages should exist rather than focusing on "X should look like Y."

@Spasi It seems alien to me. In my experience the number of errors even involving null are extremely rare relative to other programming logic errors. I think the only times I've had that exception have been in test projects with only one class file (where I don't pay attention as well as I do in normal projects and failed to initialize a String or something) and in one other case where I wrote return null; instead of something like throw new RuntimException("This method will need to be written later."); in an unused function in a recently redesigned enemy character class and forgot one class after reimplementing all the rest. It ended up having the same end result as if I had thrown an exception because it was clear that the new character caused the problem and the empty method body was as conspicuous as the exception thing. It must be because of some programming habit, but the only null reference problem I've encountered in years in a serious project was that one case. No matter what the case is, it's usually because I am being lazy and neglect to conform to what the third part class doc or my own designs specify for parameters and return values.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Spasi
« Reply #183 - Posted 2012-09-08 21:24:02 »

Actually, NPEs is the most common exception in Java programs. You don't have to believe me, just do a google search and compare NPE-related results to other runtime exceptions.
Offline jonjava
« Reply #184 - Posted 2012-09-08 21:31:28 »

Want:
1# Unsigned variables
Hate signet bytes, use for unsigned bug with chars (char always unsigned  ;))
The bits are the same regardless so it doesn't really matter.

Quote
2# Hate unavailable change some bytes of big variable

Like this :
1  
2  
3  
4  
5  
6  
7  
8  
9  
 int a = 00FF00FF
 a byte[0] add AA
that’s easy do in memory but for Java need separate bytes :(
int b =  a & 0xFF000000
int c =  ab; // Why would you need this?
b /=  0x01000000 // hm?
b += 0x000000AA; // ?
b *= 0x01000000 // ?
a = c + b; // ? :L


Quote
or simple add to int a += 0xAA000000;
but i want add byte not int =)
I don't understand. It seems you are not aware of bitwise operators? http://en.wikipedia.org/wiki/Bitwise_operation

Quote
to change RGB color need separate bytes *;*
What do you mean? Unless you want them all to be the same colour, of course you're going to need a separate byte for the Red, Green and Blue values.

Quote
(remember solution, use bytebuffer, get from it vice/versa int[] and byte[],
don’t remember why I not using it, maybe because byte signet pf  ;S, or it slow, hm)
Update(check, bytes signets, and I can’t convert bytebuffer to char array vise/versa, for unsigned byte  :()
an unsigned byte and signed byte holds the same data (bits).
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
class ByteTest {
   public static void main(String[] args) {
      byte byte1 = (byte) -1;
      byte byte2 = (byte) 255;
     
      System.out.println(byte1 == byte2);
      /*
       * Output: true
       */

   }
}


Quote
3# Want do more then 1 parent for class, interfaces not help some times.
(don’t need explanation ^^)

You do need to explain. Either make your parent inherit from another object or use interfaces. Interfaces work just as fine and are more flexible. You don't need to (shouldn't need to) make an object extend itself from multiple objects.

Quote
4# Function pointers =))
(or mega insane goto outside functions XD)

Isn't this just the same as calling a method?

Quote
5## Also want normal goto, not strange label breaks XDDDD
Want != need != useful. A goto wouldn't make sense in java (or in most modern programming languages).

Quote
6## and function for manual delete Objects ^^
1  
Object = null;

GC will do the rest. If you want to optimize GC you need to look into JVM optimization.

Quote
7## and working ASM code (JNI? Hm want integrated  code \(^;^)/)
.... WHY? Why do you play with the Nintendo if all you seem to want is to play with sticks and stones?

Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #185 - Posted 2012-09-08 21:45:52 »

Actually, NPEs is the most common exception in Java programs. You don't have to believe me, just do a google search and compare NPE-related results to other runtime exceptions.
That's probably a fallacy. The Java language and JVM are so good at preventing all the other problems that plague other systems that the next most common thing to happen, when it does happen, is an NPE. Still, I'm all for a language change that forces us to declare whether a value can be nulllable.

@Icecore - most of your suggestions seem completely mental, except the ability to have unsigned bytes (and also, the ability to write byte literals easily!)

Cas Smiley

Offline Best Username Ever

Junior Member





« Reply #186 - Posted 2012-09-08 23:23:46 »

Actually, NPEs is the most common exception in Java programs. You don't have to believe me, just do a google search and compare NPE-related results to other runtime exceptions.

I was speaking about errors (small 'e'). This includes things like off by one errors, leaving out a minus sign, precision and rounding issues with floating point numbers, changing a collection while iterating through it, infinite loops, assigning null to a variable incorrectly in a context where exceptions are still avoided, etc. And what about checked exceptions, including IOExceptions? Even if I weren't skeptical of the fact, it's a meaningless statistic. Are instances of NullPointerExceptions evenly distributed among all Java programmers? How much experience does each programmer have? Are they users or the authors of the software. Plus, Google search results are a poor metric for anything. They're based on how many copies of the phrase are found and are a very inaccurate estimation. (And by estimation I mean approximate number many orders of magnitude off from the number of links it actually can give you.)
Offline tberthel
« Reply #187 - Posted 2012-09-08 23:50:34 »

Stuff I can live without in Java:

Autoboxing
Generics
Abstract classes
IOC for everything
Casting to Interfaces for non IOC classes.
Inner classes
Anonymous classes
static classes (I don't mean singletons)
Most collections since they are too slow.

Stuff I can't live without:

Properties
Methods
Classes
Primitives
Arrays
Interfaces
Strings

Stuff I want to see in Java:

OSGI and/or Modules aka Jigsaw
Faster (Yes I know it is already fast enough.)

Offline i30817

Junior Member





« Reply #188 - Posted 2012-09-09 05:15:02 »

Am I the only one that never had NPE problems? If I ever got an NPE, even in my older n00bish days, I would go to the line number, use reasonable deduction to find out what exactly was null and where, and easily figure out my mistake. Was I special or are newbies conditioned to be dumber these days......?
It's because it's a runtime error not a compile time error like it could be if non-null was the default.
Offline Roquen
« Reply #189 - Posted 2012-09-09 06:09:18 »

I think that nullable is one of the contracts they're talking about in that annotations on types proposal (which is slated for an upcoming release). 
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline pjt33
« Reply #190 - Posted 2012-09-09 07:57:57 »

to change RGB color need separate bytes *;*
What do you mean? Unless you want them all to be the same colour, of course you're going to need a separate byte for the Red, Green and Blue values.
I think that what he means is that he wants the language to treat an int as a vector of 4 bytes so that he can manipulate packed RGB values with fewer operations. However, this is virtually useless: the only operation that you could usefully do like that would be addition with some carry bits ignored, like MMX's paddb. For practical purposes the thing to use is to use masking by 0xff00ff00 and 0x00ff00ff and operate with split sets of bytes.
Offline Spasi
« Reply #191 - Posted 2012-09-09 08:00:18 »

I was speaking about errors (small 'e'). This includes things like off by one errors, leaving out a minus sign, precision and rounding issues with floating point numbers, changing a collection while iterating through it, infinite loops, assigning null to a variable incorrectly in a context where exceptions are still avoided, etc. And what about checked exceptions, including IOExceptions? Even if I weren't skeptical of the fact, it's a meaningless statistic. Are instances of NullPointerExceptions evenly distributed among all Java programmers? How much experience does each programmer have? Are they users or the authors of the software. Plus, Google search results are a poor metric for anything. They're based on how many copies of the phrase are found and are a very inaccurate estimation. (And by estimation I mean approximate number many orders of magnitude off from the number of links it actually can give you.)

How's a NPE any different from the "errors" you describe? A bug is a bug. Even if we ignore NPE related bugs, just think about how much overhead there is in documenting (non-)nullable arguments, coding guard statements against null values, etc.

I also didn't claim scientific/statistical accuracy, my point was that NPEs is a common issue. You make it sound like it never happens. I agree that you can't expect any random google search to provide decent results, but try something like "nullpointerexception issue github".

(Btw, I'm only arguing that compile-time null-safety is a useful feature to have. Not saying that we can't live without it.)

I think that nullable is one of the contracts they're talking about in that annotations on types proposal (which is slated for an upcoming release).

Indeed. Actually, lack of type annotations is currently an issue for Kotlin-Java interop. Kotlin assumes that anything that comes from Java is nullable by default, unless a @NonNull annotation is present. But you can't have annotations on generic type parameters atm. There's IDE support to work-around it (external annotations and Kotlin signature mapping), but I don't know if/how that could be implemented outside IDEA, e.g. in the Eclipse plugin.

But... can you imagine the verbosity?

1  
@NonNull Map<@NonNull String, @Nullable Foo> map


Offline Spasi
« Reply #192 - Posted 2012-09-09 08:30:46 »

Regarding treating primitives as byte vectors, some Kotlin fun here.
Offline Icecore

Senior Member


Medals: 5



« Reply #193 - Posted 2012-09-09 08:48:22 »

I don't understand. It seems you are not aware of bitwise operators? http://en.wikipedia.org/wiki/Bitwise_operation

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
ARGB pixel
   float r_mult = 0.5f;
   float g_mult = 1;
   float b_mult = 1;

   int r1 = (int)((pixel & 0x00FF0000) * r_mult);
   r1 = r1 & 0x00FF0000;

   int g1 = (int)((pixel & 0x0000FF00) * g_mult);
   g1 = g1 & 0x0000FF00;

   int b1 = (int)((pixel & 0x000000FF) * b_mult);
   b1 = b1 & 0x000000FF;

   pixel = r1 + g1 + b1;
   pixel = pixel | 0xFF000000;//add alpha 255

if pixels in byte array then simple (unsigned ^^)
   Ar[1] *= r_mult;
   Ar[2] *= g_mult;
   Ar[3] *= b_mult;
   Ar[0] = (byte)255;



Quote
Isn't this just the same as calling a method?
Yes but - Function pointers: really good optimize code.
It will take long time to explain, and who need explanation, java don’t have them XD

Quote
You do need to explain. Either make your parent inherit from another object or use interfaces. Interfaces work just as fine and are more flexible. You don't need to (shouldn't need to) make an object extend itself from multiple objects.
Interface don’t have dynamic variables.
Example
Walk type ground class, and walk class water type,
You need rewrite them in new one class, you can’t use 2 parents.
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
Class walk{
   int speed = 10;
   int get_Speed_Walk(){return speed ;}
}
Class swim {
   int speed = 20;
   int get_Speed_Swim(){return speed ;}
}
Class Mob extends walk, swim{
   int ground_Speed = get_Speed_Walk();
   int water_Speed  = get_Speed_Swim();
}


Quote
an unsigned byte and signed byte holds the same data (bits).

If they same why I can’t do them unsigned; why I must do this B & 0xFF to convert to int =)
and
1  
2  
3  
4  
   byte a = 140;
   byte b = 10;
   byte c = (byte)(a / b);
   14 == -11 ? =)
Offline Roquen
« Reply #194 - Posted 2012-09-09 10:38:47 »

WRT: Function pointers...they're easy to fake with minimal boilerplate, so I don't find it a big deal.
WRT: Annotations/contracts: meta-data is awesome. Like any other high level language feature people are gonna use-em in screwy ways or ways that some of us won't like.  That doesn't make them less awesome.  For contracts, I've always looked at them as they're something joe average or beginner can pretty much ignore but open up things that are otherwise impossible.

In my opinion the fact that someone can (and well) write really bad code with a given feature is of about zero interest.  Once you reach the complexity of a macro assembler you've already given programmers plenty of ways to shoot themselves in the foot.  People go on about operator overloading...but think about this:  asserts.  I can't count the number of times I've seen asserts written which have side-effects and cause very difficult to track down bugs.  for-loops, with side-effect in the inc or condition block?
Offline jonjava
« Reply #195 - Posted 2012-09-09 10:59:22 »

You are using OOP/extends wrong in that example.

You don't have a firm grasp of bit manipulation and bitwise operators (they can be confusing).

http://en.wikipedia.org/wiki/Bitwise_operation
http://www.java-gaming.org/topics/transparent-colors/26829/msg/238451/view.html#msg238451
http://www.java-gaming.org/topics/tile-rendering/27088/msg/241432/view.html#msg241432

Offline Icecore

Senior Member


Medals: 5



« Reply #196 - Posted 2012-09-09 16:49:48 »

You are using OOP/extends wrong in that example.

You don't have a firm grasp of bit manipulation and bitwise operators (they can be confusing).

Maybe you right, I don’t say that I am right on all 100%
If you can optimize this with bitwise
Its really helps my software rendering .

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
public int TextureData[];
   public void set_Pixel_Color(int pos, int pixel, float r, float g, float b){
     
      int r1 = (int)((pixel & 0x00FF0000) * r);
      r1 = r1 & 0x00FF0000;
     
      int g1 = (int)((pixel & 0x0000FF00) * g);
      g1 = g1 & 0x0000FF00;
     
      int b1 = (int)((pixel & 0x000000FF) * b);
      b1 = b1 & 0x000000FF; //can be deleted , i know ;)
     
      pixel = r1 + g1 + b1;
      pixel = pixel | 0xFF000000;
     
      Texture_Data[pos] = pixel;
   }


And this ^^
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
public int TextureData[];

   public void set_Pixel_Alpha(int pos, int pixel){
      int alpha = pixel & 0xFF000000;
      if(alpha !=  0xFF000000){
         if(alpha == 0)return;      
         float a1 = (float)((alpha >> 24) & 0xFF) / 255;
         float a2 = 1 - a1;
         
         int org_pixel = TextureData[pos];
         int r1 = (int)((pixel & 0x00FF0000) * a1);
         int r2 = (int)((org_pixel & 0x00FF0000) * a2);
         int g1 = (int)((pixel & 0x0000FF00) * a1);
         int g2 = (int)((org_pixel & 0x0000FF00) * a2);
         int b1 = (int)((pixel & 0x000000FF) * a1);
         int b2 = (int)((org_pixel & 0x000000FF) * a2);
         
         r1 += r2;
         r1 = r1 & 0x00FF0000;
         
         g1 += g2;
         g1 = g1 & 0x0000FF00;
         
         b1 += b2;
         b1 = b1 & 0x000000FF;
         
         pixel = r1 + g1 + b1 ;
         pixel = pixel | 0xFF000000;          
      }

      TextureData[pos] = pixel;
   }

Offline ra4king

JGO Kernel


Medals: 345
Projects: 2
Exp: 5 years


I'm the King!


« Reply #197 - Posted 2012-09-09 18:11:05 »

You want to put R, G, and B into 1 int?

1  
int pixel = (0xff << 24) | ((r & 0xff) << 16) | ((g & 0xff) << 8) | (b & 0xff);


Then to add 2 pixels together:
1  
int pixel = (0xff << 24) | (((r1+r2) & 0xff) << 16) | (((g1+g2) & 0xff) << 8) | ((b1+b2) & 0xff);

Offline Best Username Ever

Junior Member





« Reply #198 - Posted 2012-09-09 19:18:41 »

How's a NPE any different from the "errors" you describe? A bug is a bug. Even if we ignore NPE related bugs, just think about how much overhead there is in documenting (non-)nullable arguments, coding guard statements against null values, etc.

That's my question for you. Why ignore every bug besides null reference errors? Do we also need special syntax for @NonZero to prevent divide by zero errors?

Am I the only one that never had NPE problems? If I ever got an NPE, even in my older n00bish days, I would go to the line number, use reasonable deduction to find out what exactly was null and where, and easily figure out my mistake. Was I special or are newbies conditioned to be dumber these days......?
It's because it's a runtime error not a compile time error like it could be if non-null was the default.
Btw, I'm only arguing that compile-time null-safety is a useful feature to have. Not saying that we can't live without it.

Let's say you're a total noob. If you make a mistake because you leave a variable uninitialized and its value defaults to null, you are going to eventually encounter a NullPointerException. It's going to be hard to track down because it's not the same line where null was assigned, but finding bugs is going to take a long time for you no matter what. The only debugging technique you know is to go through the code line by line. It may take a long time to find, but it's going to be way easier to find than a sign error. Not a noob? Look at the stack trace, see if you went wrong by intentionally passing null to a function that explicitly states "parameter must not be null." If so, there's your problem. If not, then go back down the stack trace, create a bunch of regular and conditional breakpoints, and see where you assigned null when you didn't mean to. Of course, none of that may even be necessary if you understand the code at a macro level. That's an easy bug to track down and fix for experts.

Can't use null? Okay, let's try an empty String, an empty List, a dummy value defined locally to this class, or use a Null Object pattern. A noob runs the program. Hmm. It doesn't work right, but there's no error message. A noob still makes the same class of mistakes and the only bug finding tool available to them is still tracing the execution of the entire program. It won't save them any time and it makes errors less likely to be found straight away. Now consider the expert making a mistake. Yes, the expert is human so even noobish mistakes will happen, just a lot less often. Well, all the tests work. The individual classes and methods involved all work correctly. It's only when you run the entire project that you have a problem. Let's try debugging? That's not as useful because I can't narrow down where the bug is coming from. Let's try adding assert statements? But what do you test for? Well, now you have to trace almost the entire project. Just like the noob, but with a much, much larger project.


Nulls and NullPointerExceptions are hugely under appreciated. They let you fail early, which is a good thing. People complain about it, but people also complain about buffering, BSODs, and sneezing. I think "null safety" is a misnomer. If you adopt coding styles that avoid breaking the contract of an API at all costs, then your chances of having null reference errors and many other problems decrease to near zero. Not coding cautiously will inevitably lead to shooting yourself in the foot. Null safety would be like using a powerful anesthesia on your foot from the start. I know having it won't necessarily encourage bad habits, but the opposite isn't true either. If I could only make one compiler change and had a choice between null safety and another solution to catch certain bugs as early as compile time, then I would leave nulls for all reference types and require all object fields to be initialized in line or in the constructor of an object, the same way final fields are.
Offline Icecore

Senior Member


Medals: 5



« Reply #199 - Posted 2012-09-09 19:19:20 »

You want to put R, G, and B into 1 int?
Not really Wink
In first code I want set color brightness.
And in second - combine 2 pixels with alpha (original pixel alpha 255 always)Wink

Offline jonjava
« Reply #200 - Posted 2012-09-09 19:36:08 »

Not really Wink
In first code I want set color brightness.
And in second - combine 2 pixels with alpha (original pixel alpha 255 always)Wink

Well, what you want != what the code does. :L

It's better not to manipulate per pixel basis unless you know exactly what you're doing.

http://death-mountain.com/2010/04/rgb-hsv-and-hue-shifting/
http://www.dig.cs.gc.cuny.edu/manuals/Gimp2/Grokking-the-GIMP-v1.0/node52.html
http://stackoverflow.com/questions/596216/formula-to-determine-brightness-of-rgb-color

Offline Spasi
« Reply #201 - Posted 2012-09-09 19:36:37 »

That's my question for you. Why ignore every bug besides null reference errors? Do we also need special syntax for @NonZero to prevent divide by zero errors?

So, just because we can't fix every possible source of bugs at compile-time, we shouldn't try fixing any of them? What kind of logic is that? And really, I don't think I have to further justify why focusing on null-safety is useful. Have you ever written a Java program without thinking about whether something can or cannot be null every few minutes?

As for the rest of your post, you're not making much sense. Null-safety isn't about removing nulls, or the ability to set a reference to null. It's about making nullability explicit at the source level, so the compiler can guarantee safe usage of such data. It's beneficial to noobs and experts alike.
Offline ags1

JGO Ninja


Medals: 48
Projects: 2
Exp: 5 years


Make code not war!


« Reply #202 - Posted 2012-09-09 19:45:47 »

You want to put R, G, and B into 1 int?

1  
int pixel = (0xff << 24) | ((r & 0xff) << 16) | ((g & 0xff) << 8) | (b & 0xff);


Then to add 2 pixels together:
1  
int pixel = (0xff << 24) | (((r1+r2) & 0xff) << 16) | (((g1+g2) & 0xff) << 8) | ((b1+b2) & 0xff);


Bitwise operators. Instant migraine.

Offline sproingie

JGO Kernel


Medals: 202



« Reply #203 - Posted 2012-09-09 19:47:57 »

That's my question for you. Why ignore every bug besides null reference errors? Do we also need special syntax for @NonZero to prevent divide by zero errors?

A PositiveInteger subtype?  That'd be awesome, can you get to work on that?  Meantime, let's get back to things that are actually tractable problems, like nullity.

NPE's are anything but "fail fast".  They're the result of a value that could have originated from anywhere, including something that's long out of scope.  Since nothing is ever forced to deal with nulls or can demand a non-null value without manually checking, the decision to handle an anonymous failure represented by a returned null gets kicked down the road until some unsuspecting code trips over it.

And no, using nonsensical defaults to avoid NPE's isn't how you deal with nullity.  The type system is one way, but a separate static constraint system in the compiler (of which a type system is one) would also be another approach, if not a perfectly ideal one.
Offline Icecore

Senior Member


Medals: 5



« Reply #204 - Posted 2012-09-09 20:13:27 »

Well, what you want != what the code does. :L
At this point : what I want = what my code does Wink
It looks so selfish, when I talking about it ^^, sorry for that =)

It already work well, it will be good if I manage optimize it XD
Offline jonjava
« Reply #205 - Posted 2012-09-09 20:20:11 »

Bitwise operators. Instant migraine.

Why it's so simple :L it's like playing with legos.

1  
2  
3  
    0101 (decimal 5)
AND 0011 (decimal 3) // AND is useful for "masking" i.e, grabbing only specific pixels you care about
 = 0001 (decimal 1)

1  
2  
3  
   0101 (decimal 5)
OR 0011 (decimal 3) // OR is useful for combining bits together
= 0111 (decimal 7)


bit shifting is so straightforward.

0100 >> 1 becomes 0010. (move the bits to the right 1 time)

0001 << 1 becomes 0010. (move the bits to the left 1 time)

an int is made up of 32 bits (=  4 bytes (1 byte = 8 bits (1 bit is either 0 or 1)))

The first byte of an int is "int & 0xFF" (bits are read from right to left).

The second byte of an int is either "int & 0xFF00" or "(int >> 8) & 0xFF"

ARGB pixel: 0000 0000 0000 0000 0000 0000 0000 0000

"int b = pixel & 0xFF":
pixel 0000 0000 0000 0000 0000 0000 0000 0000
AND   0000 0000 0000 0000 0000 0000 1111 1111   ( & 0xFF )
b   = 0000 0000 0000 0000 0000 0000 0000 0000


"int g = pixel & 0xFF00" or "int g = (pixel >> 8) & 0xFF"

pixel 0000 0000 0000 0000 0000 0000 0000 0000
AND   0000 0000 0000 0000 1111 1111 0000 0000   ( & 0xFF00 )
g   = 0000 0000 0000 0000 0000 0000 0000 0000


or

pixel      0000 0000 0000 0000 0000 0000 0000 0000
pixel >> 8 0000 0000 0000 0000 0000 0000 0000 0000
AND        0000 0000 0000 0000 0000 0000 1111 1111   ( & 0xFF )
g        = 0000 0000 0000 0000 0000 0000 0000 0000



"byte r = (pixel & 0xFF0000) >> 16"

pixel      0000 0000 0000 0000 0000 0000 0000 0000
AND        0000 0000 1111 1111 0000 0000 0000 0000   ( & 0xFF0000 )
 =         0000 0000 0000 0000 0000 0000 0000 0000
 >> 16     0000 0000 0000 0000 0000 0000 0000 0000

r        = 0000 0000   (byte can only hold 8 bits)

Offline delt0r

JGO Knight


Medals: 27
Exp: 18 years


Computers can do that?


« Reply #206 - Posted 2012-09-09 21:06:13 »

Don't forgot the signed cases with bit shifting persecutioncomplex

I have no special talents. I am only passionately curious.--Albert Einstein
Offline actual

JGO Coder


Medals: 23



« Reply #207 - Posted 2012-09-09 21:09:41 »

Quote from: sproingie
And no, using nonsensical defaults to avoid NPE's isn't how you deal with nullity.  The type system is one way, but a separate static constraint system in the compiler (of which a type system is one) would also be another approach, if not a perfectly ideal one.

Here's an interesting article on Phantom Types (I've never heard of them before). It looks like another way to use the type system to enforce certain  constraints.
Offline Best Username Ever

Junior Member





« Reply #208 - Posted 2012-09-09 21:48:48 »

@Spasi
The last time I did not stop to think about what my code did was five years ago. With the exception of the time I already described, I never have trouble with nulls. If you can't remember whether the type of map your using can store null, whether it makes sense for your program to try to store null, or what purpose storing a null key or value serves, then you're going to also have trouble with remembering whether System.arrayCopy will function correctly if you give it a String and a List<Character> (because after all, the method header takes Objects), and whether it makes sense to use a negative index to access a list, and whether it is okay to add an object to a Collection while in a for-each loop, and whether its okay to swap the values of two parameters named "min" and "max". I think you read the latter half of my post with a mental filter. I know you can make it so you can turn nullability on and off. I just don't think it solves a problem (for any language not using pointers) that professional or long time programmers haven't already learned to avoid under broader circumstances. You make programming with nulls sound like the punishment in the myth of Sisyphus. It does not take any extra energy to remind yourself "Don't use null here" if you already have to think "Don't use zero there. Make sure this collection isn't empty. Make sure I trim the spaces in this String before trying to parse it." All those things require virtually no effort anyway. Having to continuously debug code because you do not check the JavaDoc of a class, on the other hand, is much worse. Code, run, fail, debug, code again, run, fail, debug, code some more. There's a saying in carpentry and engineering: measure/calculate twice, build once. You don't need to check twice in programming unless you cannot remember something, but if you do not fail to follow the author's instructions for using a class, you never see NullPointerExceptions unless someone else's code causes the bug.

@sproingie
Pascal lets you create subtypes of integral and floating point numbers. Something like "type PostiveShort = 1..65536;" would try to fit that in two+ bytes and let you use it like a normal type. - I already said NullPointerExceptions don't occur on the same line that null gets assigned, but that's true for most errors. In practice the stack trace of most NullPointerExceptions will direct your pretty close to where the actual mistake was made if not to the same function that caused the problem. Even when it does not, then it wouldn't be a problem if you did parameter checking or assertions. Having a known value to check against makes debugging using assertions or a software debugger much easier. You can even deliberately set a reference to null when you're done with it to give you an extra opportunity to fail "fast" and make it easier to hunt down other unrelated bugs like concurrent access issues. (Similar to how streams throw an exception if you close them, but having less code, being easier to debug, and aiding the garbage collector.) That's why I related NullPointerExceptions to a person's immune system response.
Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #209 - Posted 2012-09-09 21:57:38 »

I confess to not having a great deal of trouble with NPEs - they are usually trivial to spot and occur early on and usually during testing. There are times when it'd be nice to be able to specify though.

BUE would almost certainly be in the same camp as myself and Roquen in that a design-by-contract system for Java would go a long way to preventing a lot of bugs from occurring. Whether something can or cannot be null is just one small part of a possible contract; you could just as easily specify the domain of an int to prevent it ever being < 0, for example. Pre and post conditions, constness, and invariants are nice things to be able to specify. Like generics though they have a remarkable domino effect on your code.

Cas Smiley

Pages: 1 ... 5 6 [7] 8 9 10
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

CopyableCougar4 (19 views)
2014-08-22 19:31:30

atombrot (30 views)
2014-08-19 09:29:53

Tekkerue (25 views)
2014-08-16 06:45:27

Tekkerue (23 views)
2014-08-16 06:22:17

Tekkerue (15 views)
2014-08-16 06:20:21

Tekkerue (24 views)
2014-08-16 06:12:11

Rayexar (63 views)
2014-08-11 02:49:23

BurntPizza (39 views)
2014-08-09 21:09:32

BurntPizza (31 views)
2014-08-08 02:01:56

Norakomi (38 views)
2014-08-06 19:49:38
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!