New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Warn user to use L when creating a number constant that won't fit into an int #4878

Closed
pxgator opened this Issue Feb 4, 2017 · 6 comments

Comments

Projects
None yet
4 participants
@pxgator

pxgator commented Feb 4, 2017

Processing's support for the 'long' data type is mostly useless. The statement like:
long c = 55666777888 is not allowed..?? It would be nice if the next edition would
support the use of 'long' in functions.

@gohai

This comment has been minimized.

Show comment
Hide comment
@gohai

gohai Feb 5, 2017

Contributor

Interesting. It does work when postfixing the literal with l, like so

long c = 55666777888l;

Perhaps this hint could simply added to the documentation? Or the error message? ("The literal 55666777888 of type int is out of range")

Contributor

gohai commented Feb 5, 2017

Interesting. It does work when postfixing the literal with l, like so

long c = 55666777888l;

Perhaps this hint could simply added to the documentation? Or the error message? ("The literal 55666777888 of type int is out of range")

@pxgator

This comment has been minimized.

Show comment
Hide comment
@pxgator

pxgator Feb 5, 2017

@gohai ..Interesting indeed....I'm wondering why Processing doesn't support 'long' like Java 8 does ?
But thanks a bunch for the tip as I have just tried playing with 'longs' with a postfix of upper or lower case L and it works just fine so thanks again Sir.....problem solved!! Hopefully this will be added to the documentation.

pxgator commented Feb 5, 2017

@gohai ..Interesting indeed....I'm wondering why Processing doesn't support 'long' like Java 8 does ?
But thanks a bunch for the tip as I have just tried playing with 'longs' with a postfix of upper or lower case L and it works just fine so thanks again Sir.....problem solved!! Hopefully this will be added to the documentation.

@JakubValtar

This comment has been minimized.

Show comment
Hide comment
@JakubValtar

JakubValtar Feb 6, 2017

Contributor

Processing supports long exactly like Java 8 does, long c = 55666777888; should not compile in any Java IDE (integer number too large).

We should show a better error message (number is too large for int, suffix it with L to make it long literal).

I would be against preprocessor adding L automatically, because then people are going to have other problems, e.g. when assigning to int they would have to cast to int manually or numbers would overflow.

Contributor

JakubValtar commented Feb 6, 2017

Processing supports long exactly like Java 8 does, long c = 55666777888; should not compile in any Java IDE (integer number too large).

We should show a better error message (number is too large for int, suffix it with L to make it long literal).

I would be against preprocessor adding L automatically, because then people are going to have other problems, e.g. when assigning to int they would have to cast to int manually or numbers would overflow.

@pxgator

This comment has been minimized.

Show comment
Hide comment
@pxgator

pxgator Feb 6, 2017

Thank you for the information Jakub.

pxgator commented Feb 6, 2017

Thank you for the information Jakub.

gohai added a commit to processing/processing-docs that referenced this issue Feb 10, 2017

@benfry benfry changed the title from Support for 'long' data type to Warn user to use L when creating a number constant that won't fit into an int Feb 17, 2017

@benfry benfry added the preprocessor label Feb 17, 2017

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Feb 17, 2017

Member

Changing the title to reflect the actual issue.

Member

benfry commented Feb 17, 2017

Changing the title to reflect the actual issue.

@benfry benfry added the help wanted label May 4, 2017

GKFX added a commit to GKFX/processing that referenced this issue May 20, 2017

@benfry benfry closed this in #5077 May 20, 2017

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry May 20, 2017

Member

Fix incorporated for the next release (3.4 or 3.3.4).

Member

benfry commented May 20, 2017

Fix incorporated for the next release (3.4 or 3.3.4).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment