Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust for C++ programmers – part 3: primitive types and operators

featherweightmusings.blogspot.com

Post reply on HN
Print view View original

41–50 of 68 posts

Re: Rust for C++ programmers – part 3: primitive types and operators

#41

Post by adamnemecek »

nnq wrote: post #39
nnq wrote: post #33

Earlier quoted context omitted.

99% of such bugs can be avoided in a weakly typed language by simply having the string concatenation operator different from the "+" operator (PHP has the "." operator for this, VisualBasic has "&" ...Haskell has "++" ) ...yet Javascript, Python and Ruby seem to stubbornly avoid this simple way of achieving some sort of sanity (and yeas on this one PHP is above Python and Javascript!). Also, having " " also work for…

EDIT: My bad, I retract all reference to Python, its dynamic strong typing really prevents these kings of problems. The behaviors I was thinking on happen in Javascript (and sometimes in Ruby as I recollect).

Ruby is the same as Python in this aspect.

Re: Rust for C++ programmers – part 3: primitive types and operators

#42

Post by saurik »

lifthrasiir wrote: post #34
nnq wrote: post #33

Earlier quoted context omitted.

99% of such bugs can be avoided in a weakly typed language by simply having the string concatenation operator different from the "+" operator (PHP has the "." operator for this, VisualBasic has "&" ...Haskell has "++" ) ...yet Javascript, Python and Ruby seem to stubbornly avoid this simple way of achieving some sort of sanity (and yeas on this one PHP is above Python and Javascript!). Also, having " " also work for…

No. PHP's `+` operator always tries to convert to the number, and uses 0 (!!!) when it is not possible. (e.g. what is `"hello" + "world"`?) Having different operators hardly matters; operators should cause a visible and clear error if they were given unexpected operands. Python is better in that regard since it does not allow `str + int` and so on.

FWIW, I would not call this "coercion", I'd call this "destruction": while I personally prefer languages that statically don't allow even-potentially-lossy conversions (such as string to number, or float to int) without explicit syntax bounding the error, languages that blow up at runtime if you try to numeric-add "hello" yet accept the string "0" without complaint are "acceptable" in a way that PHP (and MySQL) simply destroying data (whether by replacement or truncation) and returning/storing garbage in an attempt to satisfy the required type constraints is not :/.

Re: Rust for C++ programmers – part 3: primitive types and operators

#43

Post by masklinn »

mercurial wrote: post #40
Aqwis wrote: post #35

Earlier quoted context omitted.

Have you used Python a lot? That's not how it works. Python is not weakly typed and "string" + 5 throws an exception.

Yes (though it treats 1 as True and 0 as False, which it really ought to avoid).

Historical imperative though, for backwards compatibility with

    if some_bool == 1
or

    if isinstance(some_bool, int)
written before the bool type was added (which only happened 2.3)

Re: Rust for C++ programmers – part 3: primitive types and operators

#44

Post by masklinn »

repsilat wrote: post #31
masklinn wrote: post #29

Earlier quoted context omitted.

A colleague recently went through that as well, a (JS) graphing package would sometimes display bar charts with an incorrect scale (it would pick the wrong maximum value, so part of the bars would be cut off). Turns out the package expected numbers, but sometimes a bug meant the data source would give arrays (of a single number each), the package's own max (using <) would perform a lexical comparison (comparison woul…

Add me to the list. The other day I was debugging some simple Python code that worked something like return 10000 if x > 10000 else x and it wasn't working because x was a string. Instead of raising an exception, though, Python decided that all strings are "greater than" all integers, and code was essentially equivalent to return x

> Instead of raising an exception, though, Python decided that all strings are "greater than" all integers

Yep. That's one of the things they changed/fixed in Python 3, comparisons are not defined across and between any and all types:

    >>> "foo" > 3
    Traceback (most recent call last):
      File "", line 1, in 
    TypeError: unorderable types: str() > int()

Re: Rust for C++ programmers – part 3: primitive types and operators

#45

Post by mercurial »

mercurial wrote: post #38
b0b_d0e wrote: post #22

Earlier quoted context omitted.

Thats the rework that I'm working on! I'm debating between making a context trait and having the static function signature include a context instead of a request and the everything request related would be included/appended in the context, or having the user implement "controller" trait on their struct that has a method I will call after settling the routes (something like https://github.com/jroweboy/oxidize/blob/inc…

Personally, I'd be inclined to have the context separate from the request, since they're really two different things. Also, you could introduce a FromRequest trait (trivially implemented by Request, returning self) to allow the user to build structures directly from a request (and its converse ToResponse), giving your function a signature of: fn (context: Context, req: FromRequest) -> ToResponse trait FromRequest { f…

Ah, obviously this wouldn't work, from_request would need to return Self and not a reference for it work, which means some overhead in the case of Request, since you'd have to clone it.

Re: Rust for C++ programmers – part 3: primitive types and operators

#46

Post by kzrdude »

sisalcat wrote: post #13
nrc wrote: post #9

Earlier quoted context omitted.

All array indexing is bounds checked, so those kind of errors are prevented. We're still working on the story around overflow checking

This prevents buffer overflow errors, but not crashes.

It also prevents an equally important problem: silent passing of errors. It's common for out of bounds accesses or stores in C or C++ to just pass silently, potentially corrupting data.

Re: Rust for C++ programmers – part 3: primitive types and operators

#47

Post by azth »

dbaupp wrote: post #18
sisalcat wrote: post #16

Earlier quoted context omitted.

Yes, I can catch SIGSEGV. And I can catch Java NullPointerExceptions and ArrayIndexOutOfBoundsExceptions. So Java prevents all crashes, lol.

Yes, Java applications are rarely killed by the OS/memory manager for trying to access memory they don't have control over.

Don't argue with him/her, the parent poster is clearly acting immature.

Re: Rust for C++ programmers – part 3: primitive types and operators

#48

Post by xioxox »

I understand that there is probably a performance motivation for having int/uint having machine-dependent sizes. However, it seems to me that having different sizes on different platforms is a potential security hazard if the programmer doesn't think of this. It also gives rise to porting bugs. Isn't the idea of rust to make a securer language than C++? I would have thought mandating 32 or 64 bit for int/uint would make more sense, and if the programmer needs more or less they would have to think about that.

Re: Rust for C++ programmers – part 3: primitive types and operators

#49

Post by AlisdairO »

alkonaut wrote: post #30
sisalcat wrote: post #20

Earlier quoted context omitted.

That's a strange definition of "crash" you have there. I should go tell my customers next time that their programs definitely didn't crash.

Java raises an exception. If you handle it in code, the app does not crash. The crash is a consequence of failure to handle and recover from the exception. Granted, it is very rare that you can/should recover from nullpointer or OOB exceptions anyway. What you can do though is try to clean up things, show a polite message and shut down the application in a semi-controlled way. "Preventing crashes" isn't the best desc…

It's not that uncommon to want to recover from NPEs in a webapp environment. You want your thread of execution to error out, return a 500, and rollback whatever db changes it's made, but you want the webapp as a whole to keep running.

Re: Rust for C++ programmers – part 3: primitive types and operators

#50

Post by Ygg2 »

xioxox wrote: post #48

I understand that there is probably a performance motivation for having int/uint having machine-dependent sizes. However, it seems to me that having different sizes on different platforms is a potential security hazard if the programmer doesn't think of this. It also gives rise to porting bugs. Isn't the idea of rust to make a securer language than C++? I would have thought mandating 32 or 64 bit for int/uint would m…

I do remember a discussion on mailing list that all uint/int would be just fancy typing for u64/i64.
Post reply on HN