રસ્ટ 1.51 પ્રોગ્રામિંગ લેંગ્વેજ રિલીઝ

સિસ્ટમ પ્રોગ્રામિંગ લેંગ્વેજ રસ્ટ 1.51, મોઝિલા પ્રોજેક્ટ દ્વારા સ્થપાયેલી, પરંતુ હવે સ્વતંત્ર બિન-લાભકારી સંસ્થા રસ્ટ ફાઉન્ડેશનના આશ્રય હેઠળ વિકસિત, પ્રકાશિત કરવામાં આવી છે. ભાષા મેમરી સલામતી પર ધ્યાન કેન્દ્રિત કરે છે, સ્વચાલિત મેમરી મેનેજમેન્ટ પ્રદાન કરે છે, અને ગાર્બેજ કલેક્ટર અથવા રનટાઈમનો ઉપયોગ કર્યા વિના ઉચ્ચ કાર્ય સમાનતા પ્રાપ્ત કરવાના માધ્યમો પૂરા પાડે છે (રનટાઇમ મૂળભૂત પ્રારંભ અને પ્રમાણભૂત લાઇબ્રેરીની જાળવણી માટે ઘટાડવામાં આવે છે).

રસ્ટનું ઓટોમેટિક મેમરી મેનેજમેન્ટ પોઈન્ટર્સની હેરફેર કરતી વખતે ભૂલોને દૂર કરે છે અને લો-લેવલ મેમરી મેનીપ્યુલેશનથી ઊભી થતી સમસ્યાઓ સામે રક્ષણ આપે છે, જેમ કે મેમરી રિજનને મુક્ત કર્યા પછી એક્સેસ કરવું, નલ પોઈન્ટર ડિરેફરન્સ, બફર ઓવરરન્સ વગેરે. લાઇબ્રેરીઓનું વિતરણ કરવા, એસેમ્બલીની ખાતરી કરવા અને નિર્ભરતાઓનું સંચાલન કરવા માટે, પ્રોજેક્ટ કાર્ગો પેકેજ મેનેજર વિકસાવી રહ્યો છે. crates.io રીપોઝીટરી હોસ્ટિંગ લાઈબ્રેરીઓ માટે આધારભૂત છે.

મુખ્ય નવીનતાઓ:

• સતત જેનરિકના ઉપયોગ સાથે સંકળાયેલ કાર્યક્ષમતાને લઘુત્તમ વ્યવહારુ ઉત્પાદન (MVP) નો દરજ્જો મળ્યો છે, જે વ્યાપક ઉપયોગ માટે લીલી ઝંડી આપે છે. કોન્સ્ટ જેનરિક્સ પ્રકારોને સ્થિર મૂલ્યોમાં સામાન્યીકરણ કરવાની મંજૂરી આપે છે, એટલે કે. સતત મૂલ્યોની શ્રેણી સુધી મર્યાદિત સામાન્ય દલીલોનો ઉપયોગ કરો, પ્રકારો અથવા જીવનકાળ માટે નહીં. આ સુવિધા તમને કોઈપણ કદના એરે માટે લક્ષણો બનાવતી વખતે પૂર્ણાંક-પેરામીટરાઇઝ્ડ પ્રકારો અને એબ્સ્ટ્રેક્શનનો ઉપયોગ કરવાની મંજૂરી આપે છે જેથી ખાતરી કરી શકાય કે ત્યાં કોઈ સીમા બહારની ઘટનાઓ નથી.

  વર્તમાન પ્રકાશનથી શરૂ કરીને, પ્રકાર “[T; N]" (પ્રકાર T અને કદ N) કોઈપણ પૂર્ણાંક, બુલિયન અને અક્ષર પ્રકારો (સ્ટ્રક્ચર અને એનમ પ્રકારો હજુ સુધી સમર્થિત નથી) સાથે મૂલ્યોનો ઉપયોગ કરીને અમૂર્ત પ્રકાર અને કદની ક્ષમતા પ્રદાન કરે છે. કોન્સ્ટન્ટ જેનરિક લાઇબ્રેરી ડેવલપમેન્ટને મોટા પ્રમાણમાં સરળ બનાવે છે; ઉદાહરણ તરીકે, ચોક્કસ પ્રકાર અને કદ સાથે બંધાયેલ ન હોય તેવા એરેનો ઉપયોગ કરવા માટે, તમે સ્પષ્ટ કરી શકો છો: સ્ટ્રક્ટ એરે { // ^^^^^^^^^^^^^^^^^^^^ સતત સામાન્ય સૂચિની વ્યાખ્યા: [T; લંબાઈ] // ^^^^^^ તેનો ઉપયોગ }

  જ્યારે ખરેખર "એરે" ની આ વ્યાખ્યા સાથે વપરાય છે » કમ્પાઈલર એરેનું મોનોમોર્ફિક વર્ઝન જનરેટ કરશે: સ્ટ્રક્ટ એરે { યાદી: [u8; 32] }

• std::array::IntoIter API, સતત જેનરિક પર આધારિત, સ્થિર કરવામાં આવ્યું છે, જેની સાથે તમે કોઈપણ એરે માટે મૂલ્ય દ્વારા પુનરાવર્તનો બનાવી શકો છો: fn main() { let array = [1, 2, 3, 4, 5] ; // અગાઉ, મૂલ્ય પર પુનરાવર્તિત કરવા માટે, તમારે array.iter().copied() { println!("{}", આઇટમ); } // હવે તમે std::array::IntoIter::new(array) { println!("{}", આઇટમ) માં આઇટમ માટે સ્પષ્ટ કરી શકો છો; } }
• કાર્ગો પેકેજ મેનેજર હવે Cargo.toml માં નવા રિઝોલ્વર ફીલ્ડને સપોર્ટ કરે છે, જેનો ઉપયોગ ફિચર રિઝોલ્વરના બીજા વર્ઝનને સક્ષમ કરવા માટે થઈ શકે છે. નિર્ધારકનું નવું સંસ્કરણ "[સુવિધાઓ]" વિભાગમાં સૂચિબદ્ધ નિર્ભરતા સુવિધાઓને સંયોજિત કરવાનું ટાળે છે જ્યાં તે અયોગ્ય છે, ઉદાહરણ તરીકે, જ્યારે બિલ્ડ સ્ક્રિપ્ટ્સ અને મેક્રોમાં કેટલીક માનક સુવિધાની વિનંતી કરતી નિર્ભરતાનો સમાવેશ થાય છે, પરંતુ જ્યારે બિન-માનક સુવિધાનો ઉપયોગ કરવામાં આવે છે. પરિણામી એક્ઝેક્યુટેબલ ફાઇલમાં.

  અત્યાર સુધી, ડિપેન્ડન્સી ગ્રાફમાં ઘણી વખત ઉલ્લેખિત પેકેજની ક્ષમતાઓને જોડવામાં આવી હતી. ઉદાહરણ તરીકે, જો કોઈ પ્રોજેક્ટમાં A અને B ક્ષમતાઓને વ્યાખ્યાયિત કરતી ડિપેન્ડન્સી fooનો સમાવેશ થાય છે, અને આ પૅકેજનો ઉપયોગ અન્ય પૅકેજ બાર અને બાઝમાં થાય છે, તેમ છતાં બાર ફીચર A સાથે foo પર આધાર રાખે છે, અને baz ફીચર B સાથે foo પર આધાર રાખે છે, તો પછી પરિણામ એ આવશે કે કાર્ગો આ ​​સુવિધાઓને સંયોજિત કરશે અને foo ને A અને B સમાવિષ્ટ સુવિધાઓ સાથે કમ્પાઇલ કરશે. આ પદ્ધતિ એક એવી સુવિધામાં પરિણમી શકે છે જે અમુક નિર્ભરતા લક્ષ્ય સિસ્ટમ સાથે અસંગત હોવાને કારણે સક્ષમ છે જેના માટે પરિણામી બિલ્ડ બનાવવામાં આવે છે. ઉદાહરણ તરીકે, જ્યારે તમે "#![no_std]" સાથે બિલ્ટ એક્ઝિક્યુટેબલમાં "#![no_std]" સાથે foo ના વર્ઝનનો ઉપયોગ કરવા માંગતા હો, અને તે જ સમયે બિલ્ડ ઇન બિલ્ડ દરમિયાન "std" સાથે foo નો ઉપયોગ કરો. રૂ. Cargo.toml માં રિઝોલ્વર="2" નો ઉલ્લેખ કરતી વખતે, પેકેજ મેનેજર હવે dev, યજમાન અને લક્ષ્ય નિર્ભરતાને અલગ કરીને, આ સંઘર્ષને યોગ્ય રીતે હેન્ડલ કરવાનો પ્રયાસ કરશે.

• કાર્ગો સ્પ્લિટ-ડિબગિનફો વિકલ્પને અમલમાં મૂકે છે, જે “[પ્રોફાઇલ]” વિભાગમાં સેટ છે, અને અનુરૂપ ફ્લેગ “-Csplit-debuginfo=unpacked” rustc માં, ડિબગીંગ માહિતીને બચાવવા માટે નવી પદ્ધતિના અમલીકરણની ઓફર કરે છે, જે જરૂરિયાતને દૂર કરે છે. dsymutil ઉપયોગિતાને કૉલ કરો અને macOS પર ડિબગીંગ માહિતી સાથે પ્રક્રિયાના નિર્માણને નોંધપાત્ર રીતે ઝડપી બનાવે છે.
• સ્થિર મકોસ "ptr::addr_of!" અને “ptr::addr_of_mut!”, જે તમને અસંરેખિત ક્ષેત્રો માટે કાચા પોઇન્ટર બનાવવાની મંજૂરી આપે છે. std::ptr નો ઉપયોગ કરો; #[repr(packed)] struct Packed { f1: u8, f2: u16, } let packed = Packed { f1: 1, f2: 2 }; // &packed.f2 એક અસંબંધિત પોઇન્ટર બનાવશે જે અવ્યાખ્યાયિત વર્તન તરફ દોરી જશે raw_f2 = ptr::addr_of!(packed.f2); assert_eq!(અસુરક્ષિત { raw_f2.read_unaligned() }, 2);
• API ના એક નવા ભાગને સ્થિર શ્રેણીમાં સ્થાનાંતરિત કરવામાં આવ્યો છે, જેમાં નીચેની પદ્ધતિઓનો સમાવેશ કરીને સ્થિર કરવામાં આવી છે:
  • આર્ક::decrement_strong_count
  • આર્ક::increment_strong_count
  • એકવાર::કૉલ_વન્સ_ફોર્સ
  • પીકેબલ::next_if_eq
  • પીકેબલ::next_if
  • શોધો::stream_position
  • array::IntoIter
  • panic::panic_any
  • ptr::addr_of!
  • ptr::addr_of_mut!
  • સ્લાઇસ::ફિલ_વિથ
  • સ્લાઇસ::સ્પ્લિટ_સમાવિષ્ટ_મટ
  • સ્લાઇસ::સ્પ્લિટ_સમાવિષ્ટ
  • સ્લાઇસ::સ્ટ્રીપ_પ્રીફિક્સ
  • સ્લાઇસ::સ્ટ્રીપ_સફિક્સ
  • str::split_inclusive
  • સિંક::વન્સસ્ટેટ
  • કાર્ય::જાગો
• i386-unknown-linux-gnu, i486-unknown-linux-gnu, aarch64_be-unknown-linux-gnu, aarch64-unknown-linux-gnu_ilp32 અને aarch64_be-unknown-linux-gnu_ilp32 પ્લેટફોર્મ્સ માટે સમર્થનનું ત્રીજું સ્તર લાગુ કરવામાં આવ્યું છે. . ત્રીજા સ્તરમાં મૂળભૂત આધારનો સમાવેશ થાય છે, પરંતુ સ્વયંસંચાલિત પરીક્ષણ વિના, સત્તાવાર બિલ્ડ પ્રકાશિત કરવા અથવા કોડ બનાવી શકાય છે કે કેમ તે તપાસ્યા વિના.

સોર્સ: opennet.ru