2017-06-22 56 views
7

此問題與When is it useful to define multiple lifetimes in a struct?類似,但希望不同。這個問題的答案是有幫助的,但是關注一種方法的優點(在struct中使用不同的生命期),而不是缺點(如果有的話)。這個問題就像這樣,正在尋找如何在創建結構時選擇生命週期的指導。爲什麼你會在結構中使用相同的生命週期參考?

稱此爲綁在一起版本,因爲Xÿ需要具有相同的壽命:

struct Foo<'a> { 
    x: &'a i32, 
    y: &'a i32, 
} 

和稱此爲鬆散版本,因爲壽命可以變化:

struct Foo<'a, 'b> { 
    x: &'a i32, 
    y: &'b i32, 
} 

對引用問題的回答給出了一個明確的例子:客戶端代碼可以編譯/運行給定寬鬆版本,但將連接在一起版本失敗。是不是說,對於適用於任何客戶端代碼捆綁在一起版本還將爲寬鬆版工作,將得到保證的情況下一樣安全(即安全的)?正面是不正確的。從結構設計師的角度來看,寬鬆的版本顯然更加靈活。鑑於這是一個很好/被接受的答案,指導可能是 - 當在結構中使用引用總是給它們不同的生命期。

這個建議的缺點是什麼,忽略了額外的輸入?例如,是否有益於要求引用在結構體中具有相同的生命週期?

回答

5

是否有過利於需要在結構中引用具有相同的壽命

是的,它超越了具有結構。如果壽命總是有別於對方,那麼你可以不寫這樣的功能:

fn foo<'a, 'b>(a: &'a str, b: &'b str) -> &str { // What lifetime to return? 
    if (global_random_number() == 42) { a } else { b } 
} 

應用的結構,你可以有這樣的事情:

struct EvenOrOdd<'a, 'b> { 
    even: &'a str, 
    odd: &'b str, 
} 

impl<'a, 'b> EvenOrOdd<'a, 'b> { 
    fn do_it(&self, i: u8) -> &str { 
     if i % 2 == 0 { 
      self.even 
     } else { 
      self.odd 
     } 
    } 
} 

注意的是,雖然這個編譯,它不會返回一個字符串,它可以超過結構本身,這不是預期的。此代碼失敗,即使它應該能夠工作:

fn foo<'a, 'b>(a: &'a str, b: &'b str) { 
    let result = { 
     EvenOrOdd { even: a, odd: b }.do_it(42) 
    }; 

    println!("{}", result); 
} 

這將統一壽命工作:

struct EvenOrOdd<'a> { 
    even: &'a str, 
    odd: &'a str, 
} 

impl<'a> EvenOrOdd<'a> { 
    fn do_it(&self, i: u8) -> &'a str { 
     if i % 2 == 0 { self.even } else { self.odd } 
    } 
} 

這是鏈接的答案相反,它有註釋:

要能夠採取的總值,並用它

之後分出其中的一部分

在這種情況下,我們要取一個合計值和統一他們。

在極少數情況下,您可能需要不同的線程和統一的壽命之間的針:

struct EvenOrOdd<'a, 'b: 'a> { 
    even: &'a str, 
    odd: &'b str, 
} 

impl<'a, 'b> EvenOrOdd<'a, 'b> { 
    fn do_it(&self, i: u8) -> &'a str { 
     if i % 2 == 0 { self.even } else { self.odd } 
    } 
} 

雖然這是非常有用的需要的時候,我無法想象的哀號和咬牙切齒會爆發,如果我們每次都必須這樣寫。


忽略了額外的輸入

我不會。有

foo<'a>(Bar<'a>) 

絕對優於

foo<'a, 'b', 'c, 'd>(Bar<'a, 'b', 'c, 'd>) 

當你不是從額外的通用參數中受益。

+0

Maybe * foo <...>(... b:&str)*應該是* foo <...>(... b:'b&str)*?奇怪的沒有編譯器錯誤或警告未使用的範圍'b。 隨着原來的問題,我認爲需要不同的生活時間是非常人爲的。但是,嘿,如果可能發生,就讓他們獨立。我認爲這個例子顯示了同樣的生活時間的優點也是非常人爲的。誰知道客戶可能面臨的所有潛在的終生問題(或應該知道)?讓額外的打字指導我回到只是設置它們相同。不幸的是,一旦選擇改變並不容易。 – user1338952

+0

涵蓋主題的任何博客(即*爲您的結構選擇生命期時的*軟件設計*選擇)?這比以下多一點:它是如何工作的。預發行書*編程鏽*有部分*不同的壽命參數*觸及問題。似乎建議先嚐試一樣,如果你發現你需要它們獨立更換它們。不確定的比例。 – user1338952

相關問題