3 ms·

Signed-only ints is really painful when working with binary formats, for sure. But the rules around unsigned vs signed ints in C/C++ are pretty painful. -fwrapv

Signed-only ints is really painful when working with binary formats, for sure. But the rules around unsigned vs signed ints in C/C++ are pretty painful. -fwrapv shouldn't exist. There is a library (GNU Trove) that provides specialised containers for primitives. It'd be nice if the language had them built in, but they're only quite rarely needed it seems. Normally there's some wrapper type involved. Java has scoped 'destruction' (called try-with-resources). An equivalent for 'auto' is coming to Java, though Kotlin has it already.

Rusky 9y ago
> Java has scoped 'destruction' (called try-with-resources). This is nicer than manually writing `finally` blocks, but it's nowhere near as nice as RAII-style destructors, which you can't accidentally leave out.
- pjmlp 9y ago
  Sure you can, you just need to allocate them on the heap and forget about calling delete on them or not properly handle exceptions. Not everyone is writing C++ as they should.
cesarb 9y ago
> Java has scoped 'destruction' (called try-with-resources). Java's try-with-resources (and Kotlin's equivalent, .use()) are a start, but C++'s (and Rust's) ownership model is stronger. Java's model works fine when the resource doesn't have to escape the try block (and when you never forget to use the try block). But if you have a resource which might or might not escape the block (that is, its ownership might be to be passed to the caller, or to a separate long-living object), you have to do it manually, and if you're not very careful, you can have places where a stray exception leads to a resource leak. (Yes, this bit us recently at work, both the stray exception and the "another programmer didn't call .close()". Workaround for the later: finalize()...) In "modern" C++ style (which avoids manual new/delete most of the time, instead using unique_ptr and similar), ownership transfer is easier to make reliable: you can move the ownership into the return value or into another object, without leaving any gaps where a stray exception could leak the resource. And the default is to have ownership, so less chance of leaks due to forgetting to use a try block. Rust makes it even easier to avoid such leaks (outside of reference cycles, unsafe code using raw pointers, and the "leak it on purpose" mem::forget function).

Rusky 9y ago

> Java has scoped 'destruction' (called try-with-resources). This is nicer than manually writing `finally` blocks, but it's nowhere near as nice as RAII-style destructors, which you can't accidentally leave out.

pjmlp 9y ago
Sure you can, you just need to allocate them on the heap and forget about calling delete on them or not properly handle exceptions. Not everyone is writing C++ as they should.

cesarb 9y ago

> Java has scoped 'destruction' (called try-with-resources). Java's try-with-resources (and Kotlin's equivalent, .use()) are a start, but C++'s (and Rust's) ownership model is stronger. Java's model works fine when the resource doesn't have to escape the try block (and when you never forget to use the try block). But if you have a resource which might or might not escape the block (that is, its ownership might be to be passed to the caller, or to a separate long-living object), you have to do it manually, and if you're not very careful, you can have places where a stray exception leads to a resource leak. (Yes, this bit us recently at work, both the stray exception and the "another programmer didn't call .close()". Workaround for the later: finalize()...) In "modern" C++ style (which avoids manual new/delete most of the time, instead using unique_ptr and similar), ownership transfer is easier to make reliable: you can move the ownership into the return value or into another object, without leaving any gaps where a stray exception could leak the resource. And the default is to have ownership, so less chance of leaks due to forgetting to use a try block. Rust makes it even easier to avoid such leaks (outside of reference cycles, unsafe code using raw pointers, and the "leak it on purpose" mem::forget function).