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

21–30 of 68 posts

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

#21

Post by guelo »

dbaupp wrote: post #14
b0b_d0e wrote: post #10

Earlier quoted context omitted.

index out of bounds errors are handled in separate ways depending on the kind of array you are using. If I understand how it works correctly, you can be working with one of three main kinds of arrays: slices with a known length, slices with an unknown length, or a growable vector. In the case of slices with a known length, ie: let a = [0]; then trying to say a[1] is a compile error since the compiler knows the length…

Indexing a fixed-length array (I.e. known at compile time) out of bounds is not prohibited at compile time. All array types trigger a task failure on out-of-bounds access (unless you explicitly opt-in to unchecked indexing).

I was going to ask if array[random_integer()] would compile only some of the time.

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

#22

Post by b0b_d0e »

mercurial wrote: post #19
b0b_d0e wrote: post #7

Earlier quoted context omitted.

Kinda, yes, but not really. Currently, the best http framework in Rust is rust-http ( https://github.com/chris-morgan/rust-http ) and it has the things needed for handling requests and sending responses. But as far as actual full featured web frameworks, there is only one that I know of (discounting mre since it hasn't been updated in a long time) and that's because I am the creator of it. oxidize ( https://github.co…

What I like about it is that it's pretty devoid of macros. I'm curious as to how you are planning to handle the environment of the webapp (configuration, connection pool, business objects...), given that you settled for plain functions with a given signature.

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/incoming/tmp/matchb... where maybe a macro can generate this method from the urls. Note that this code doesn't compile though :) While I was initially fond of the latter, it's been very painful to work with in practice and I don't see it actually working, so I think that I'll be testing out to see if I can rework the static functions to have a context. I think the hardest part is that I want to eliminate any need to have any static variables, but that means I have to store them all in a struct that requires Send to be fulfilled and thats more over head for programmers. In the near future, I will be looking into using the different parts of rust-http directly rather than implementing the server trait to see if I can gain any benefits from that :)

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

#23

Post by b0b_d0e »

dbaupp wrote: post #14
b0b_d0e wrote: post #10

Earlier quoted context omitted.

index out of bounds errors are handled in separate ways depending on the kind of array you are using. If I understand how it works correctly, you can be working with one of three main kinds of arrays: slices with a known length, slices with an unknown length, or a growable vector. In the case of slices with a known length, ie: let a = [0]; then trying to say a[1] is a compile error since the compiler knows the length…

Indexing a fixed-length array (I.e. known at compile time) out of bounds is not prohibited at compile time. All array types trigger a task failure on out-of-bounds access (unless you explicitly opt-in to unchecked indexing).

Oh thanks for clearing that up! Is there any specific reason why the rust compilier currently doesn't check that a static int accessing into a known length slice doesn't result in a compile error? (I'm only referring to cases where the index you are trying to access is known at compile time as well as the length of the slice)

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

#24

Post by Jweb_Guru »

sisalcat wrote: post #11
b0b_d0e wrote: post #10

Earlier quoted context omitted.

index out of bounds errors are handled in separate ways depending on the kind of array you are using. If I understand how it works correctly, you can be working with one of three main kinds of arrays: slices with a known length, slices with an unknown length, or a growable vector. In the case of slices with a known length, ie: let a = [0]; then trying to say a[1] is a compile error since the compiler knows the length…

> it will cause a task failure i.e. a crash.

Not at all. Tasks can (and do) die without killing the main program. They also don't segfault, and as the stack unwinds destructors get called (which Rust can actually ensure is safe). If you've ever had the pleasure of dealing with a framework that likes to send SIGKILL indiscriminately to important programs, you'll appreciate the difference between the two.

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

#27

Post by nikbackm »

b0b_d0e wrote: post #23
dbaupp wrote: post #14

Earlier quoted context omitted.

Indexing a fixed-length array (I.e. known at compile time) out of bounds is not prohibited at compile time. All array types trigger a task failure on out-of-bounds access (unless you explicitly opt-in to unchecked indexing).

Oh thanks for clearing that up! Is there any specific reason why the rust compilier currently doesn't check that a static int accessing into a known length slice doesn't result in a compile error? (I'm only referring to cases where the index you are trying to access is known at compile time as well as the length of the slice)

It would be inconsistent and not really that helpful. How often do you use (invalid) constant indexes with fixed length arrays?

Probably better to handle all out-of-bounds errors the same way.

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

#28

Post by saurik »

mercurial wrote: post #4

Having been the victim of a fun Javascript bug recently (something like ("1" + 10)*2), I must say that I agree that type coercion is the wrong thing to do 99% of the time (probably with the exception of attempting to divide integers).

It isn't as much about the coercion as the consistency: the division case returning a float when given integers is fine if the division operator always does that. Some languages (VB being an example; I wish more were) have a "string concatenation" operator that is separate from numeric addition; 1 & 2 is always going to be "12".

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

#29

Post by masklinn »

mercurial wrote: post #4

Having been the victim of a fun Javascript bug recently (something like ("1" + 10)*2), I must say that I agree that type coercion is the wrong thing to do 99% of the time (probably with the exception of attempting to divide integers).

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 would coerce to string and a graph with a value at 800 and one at 1800 would pick a y-scale for 800 and cut off 1800) but further operations would coerce to number, so there was no error anywhere and most graphs looked correct.

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

#30

Post by alkonaut »

sisalcat wrote: post #20
dbaupp wrote: post #18

Earlier quoted context omitted.

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

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 description of Rust's novel protection systems. In my opinion, the best part is providing guarantees about data integrity and security, e.g. preventing heartbleed type read-overruns and preventing data races in concurrent code due to shared mutable state.

Post reply on HN