it-ebooks - A Guide to Porting C C++ to Rust
Here you can read online it-ebooks - A Guide to Porting C C++ to Rust full text of the book (entire story) in english for free. Download pdf and epub, get meaning, cover and reviews about this ebook. year: 2018, publisher: iBooker it-ebooks, genre: Computer. Description of the work, (preface) as well as reviews are available. Best literature library LitArk.com created for fans of good reading and offers a wide selection of genres:
Romance novel
Science fiction
Adventure
Detective
Science
History
Home and family
Prose
Art
Politics
Computer
Non-fiction
Religion
Business
Children
Humor
Choose a favorite category and find really read worthwhile books. Enjoy immersion in the world of imagination, feel the emotions of the characters or learn something new for yourself, make an fascinating discovery.
A Guide to Porting C C++ to Rust: summary, description and annotation
We offer to read an annotation, description, summary or preface (depends on what the author of the book "A Guide to Porting C C++ to Rust" wrote himself). If you haven't found the necessary information about the book — write in the comments, we will try to find it.
A Guide to Porting C C++ to Rust — read online for free the complete book (whole text) full work
Below is the text of the book, divided by pages. System saving the place of the last page read, allows you to conveniently read the book "A Guide to Porting C C++ to Rust" online for free, without having to search again every time where you left off. Put a bookmark, and you can go to the page where you finished reading at any time.
Font size:
Interval:
Bookmark:
- 1.1
- 1.2
- 1.3
- 1.4
- 1.5
- 1.6
- 1.7
- 1.8
- 1.9
- 1.10
- 1.11
- 1.12
- 1.13
- 1.14
- 1.14.1
- 1.14.2
- 1.14.3
- 1.14.4
- 1.14.5
- 1.14.6
- 1.14.7
- 1.14.8
- 1.14.9
- 1.14.10
- 1.14.11
- 1.14.12
- 1.14.13
- 1.14.14
- 1.14.15
- 1.14.16
- 1.14.17
- 1.14.18
- 1.14.19
- 1.14.20
- 1.14.21
- 1.14.22
- 1.14.23
- 1.14.24
- 1.14.25
- 1.15
- 1.15.1
- 1.15.2
- 1.15.3
- 1.15.4
- 1.15.5
- 1.15.6
- 1.15.7
- 1.15.8
- 1.15.9
- 1.15.10
- 1.15.11
- 1.15.12
- 1.15.13
- 1.15.14
- 1.15.15
- 1.15.16
- 1.15.17
- 1.15.18
- 1.16
- 1.17
- 1.18
- 1.19
The omission of an =
in an ==
condition turns it into an assignment that evaluates to true:
int result = getResponseCode(); if (result = ) { // BUG! // Success } else { //... Process error }
So here, result was assigned the value 200 rather than compared to the value 200. Compilers shouldissue a warning for these cases, but an error would be better.
Developers might also try to reverse the left and right hand side to mitigate the issue:
if ( = result) { // Compiler error // Success } else { // ... Process error }
Now the compiler will complain because the value of result is being assigned to a constant which makes no sense. This may work if a variable is compared to a constant but arguably it makes the code less readable and wouldn't help if the left and right hand sides were both assignable so their order didn't matter.
The goto fail
example that we saw in section "Missing braces in conditionals" also demonstrates a real world dangers combining assignment and comparison into a single line:
if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != ) goto fail;
This line is not broken for other reasons, but it's easy to see how might be, especially if this pattern were repeated all over the place. The programmer might have saved a few lines of code to combine everything in this way but at a greater risk. In this case, the risk might be inadvertantly turning the =
into an ==
, i.e. comparing err to the function call and then comparing that to 0.
if ((err == SSLHashSHA1.update(&hashCtx, &serverRandom)) != ) goto fail;
This code just won't compile:
let mut result = ; if result = { // Compile Error //... }
The only form of assignment inside a conditional is the specialised and explicit if let
and while let
forms which are explained elsewhere.
C++ has various ways to give compiler directives during compilation:
- Compile flags that control numerous behaviours
#pragma
statements -once
,optimize
,comment
,pack
etc. Some pragmas such ascomment
have been wildly abused in some compilers to insert "comments" into object files that control the import / export of symbols, static linking and other functionality.#define
with ubquitous#ifdef
/#else
/#endif
blocks- Keywords
inline
,const
,volatile
etc.. These hint the code and allow the compiler to make decisions that might change its output or optimization. Compilers often have their own proprietary extensions.
Rust uses a notation called attributes that serves a similar role to all of these things but in a more consistent form.
An attribute #[foo]
applies to the next item it is declared before. A common attribute is used to denote a unit test case with #[test]
:
#[test] fn this_is_a_test () { //... }
Attributes can also be expressed as #![foo]
which affects the thing they're contained by rather the thing that follows them.
fn this_is_a_test () { #![test] //... }
Attributes are enclosed in a #[ ]
block and provide compiler directives that allow:
- Functions to be marked as unit or benchmark tests
- Functions to be marked for conditional compilation for a target OS. A function can be defined that only compiles for one target. e.g. perhaps the code that communicates with another process on Windows and Linux is encapsulated in the same function but implemented differently.
- Enable / disable lint rules
- Enable / disable compiler features. Certain features of rust may be experimental or deprecated and may have to be enabled to be accessed.
- Change the entry point function from
main
to something else - Conditional compilation according to target architecture, OS, family, endianess, pointer width
- Inline hinting
- Deriving certain traits
- Enabling compiler features such as plugins that implement procedural macros.
- Importing macros from other crates
- Used by certain crates like serde and rocket to instrument code - NB Rocket uses unstable compiler hooks for this and in so doing limits itself to working in nightly builds only.
Conditional compilation allows you to test the target configurations and optionally compile functions or modules in or not.
The main configurations you will test include:
- Target architecture - "x86", "x86_64", mips", "arm" etc.
- Target OS - "windows", "macos", "ios", "linux", "android", "freebsd" etc.
- Target family - "unix" or "windows"
- Target environment - "gnu", "msvc" etc
- Target endianess
- Target pointer width
So if you have a function which is implemented one way for Windows and another for Linux you might code it like so:
#[cfg(windows)] fn get_app_data_dir () -> String { /* ... */ } #[cfg(not(windows))] fn get_app_data_dir () -> String { /* ... */ }
Many more possibilities are listed in the documentation.
In C/C++ code is first compiled and then it is linked, either by additional arguments to the compiler, or by invoking a linker.
In Rust most of your linking is taken care for you providing you use cargo
.
- All your sources are compiled and linked together.
- External crates are automatically built as static libs and linked in.
- But if you have to link against something external through FFI you have to write a
#link
directive in yourlib.rs
ormain.rs
. This is somewhat analogous to the#pragma(comment, "somelib")
in C++.
C++ | Rust |
---|---|
#pragma (comment, "somelib") | #[link(name = "somelib")] |
- | #[link(name = "somelib", kind = "static")] |
The default kind for #link
is dynamic
library but static
can be explicitly stated specified.
Inlining happens where your function logic is inserted in-place to the code that invokes it. It tends to happen when the function does something trivial such as return a value or execute a simple conditional. The overhead of duplicating the code is outweighed by the performance benefit.
Font size:
Interval:
Bookmark:
Similar books «A Guide to Porting C C++ to Rust»
Look at similar books to A Guide to Porting C C++ to Rust. We have selected literature similar in name and meaning in the hope of providing readers with more options to find new, interesting, not yet read works.
Discussion, reviews of the book A Guide to Porting C C++ to Rust and just readers' own opinions. Leave your comments, write what you think about the work, its meaning or the main characters. Specify what exactly you liked and what you didn't like, and why you think so.