Eu sei que, em geral, as variáveis globais devem ser evitadas. No entanto, acho que em um sentido prático, às vezes é desejável (em situações em que a variável é parte integrante do programa) usá-los.
Para aprender Rust, estou atualmente escrevendo um programa de teste de banco de dados usando sqlite3 e o pacote Rust / sqlite3 no GitHub. Conseqüentemente, isso necessita (em meu programa de teste) (como uma alternativa para uma variável global), para passar a variável de banco de dados entre funções das quais existem cerca de uma dúzia. Um exemplo está abaixo.
É possível, viável e desejável usar variáveis globais em Rust?
Dado o exemplo abaixo, posso declarar e usar uma variável global?
extern crate sqlite;
fn main() {
let db: sqlite::Connection = open_database();
if !insert_data(&db, insert_max) {
return;
}
}
Tentei o seguinte, mas não parece estar certo e resultou nos erros abaixo (também tentei com um unsafe
bloco):
extern crate sqlite;
static mut DB: Option<sqlite::Connection> = None;
fn main() {
DB = sqlite::open("test.db").expect("Error opening test.db");
println!("Database Opened OK");
create_table();
println!("Completed");
}
// Create Table
fn create_table() {
let sql = "CREATE TABLE IF NOT EXISTS TEMP2 (ikey INTEGER PRIMARY KEY NOT NULL)";
match DB.exec(sql) {
Ok(_) => println!("Table created"),
Err(err) => println!("Exec of Sql failed : {}\nSql={}", err, sql),
}
}
Erros resultantes da compilação:
error[E0308]: mismatched types
--> src/main.rs:6:10
|
6 | DB = sqlite::open("test.db").expect("Error opening test.db");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected enum `std::option::Option`, found struct `sqlite::Connection`
|
= note: expected type `std::option::Option<sqlite::Connection>`
found type `sqlite::Connection`
error: no method named `exec` found for type `std::option::Option<sqlite::Connection>` in the current scope
--> src/main.rs:16:14
|
16 | match DB.exec(sql) {
| ^^^^
Connection
dentro de um Option<Connection>
tipo e tentar usar um Option<Connection>
como a Connection
. Se esses erros fossem resolvidos (usando Some()
) e eles usassem um unsafe
bloco, como tentaram originalmente, seu código funcionaria (embora de maneira insegura para threads).