Konu Sahibi
Konu Sahibi
Ayyıldız2 | 2008 TR Yapısı • 1-99 Orta Emek Destan • Oto Avsız • 10 Temmuz 21:00 HEMEN TIKLA!
Bu arada yazıda söylemeyi unutmuşum, copy assignment operatorda copy-swap idiomu tercih edilebilir, ben special member funcları örnek olarak basitçe yazdım çok takılmayın, kullanacaksanız implementasyonu size kalmış buffer_new vb. API'lara bakmadan hareket etmeyin sorumluluk size ait
Şu kısımda büyük bi patladım hakkını helal et asfmklasdgömklasdglasdg forum bayağı seviye atlamış AI çıktığından beri. Bu gidişte metin2'yi unreal'da falan da çalıştıracaklar az kaldı xDD
sıra bende
Eline sağlık, tespit bence doğru. TEMP_BUFFER burada value-semantic bir tip gibi değil, ownership taşıyan geçici bir RAII wrapper gibi davranıyor. Bu yüzden benim de ilk tercihim deep copy yazmak değil, copy ctor ve copy assignment’ı tamamen kapatmak olurdu.
TEMP_BUFFER(const TEMP_BUFFER&
= delete;<br>TEMP_BUFFER& operator=(const TEMP_BUFFER& = delete;<br>
Çünkü deep copy yazınca sınıfa “kopyalanabilir ve aynı state’i korur” anlamı yüklenmiş oluyor. Ama senin de not düştüğün gibi read point, flag/state vb. her şey birebir taşınmıyorsa bu sefer başka bir yanıltıcı davranış doğabilir. TEMP_BUFFER paket oluşturma tarafında geçici buffer gibi kullanılıyorsa copy-delete çok daha net ve güvenli.
Move tarafı için de uyarın yerinde. User-declared destructor olduğu için move ctor / move assignment otomatik gelmiyor. Copy’leri delete edince sınıf move da edilemiyorsa, ileride std::move, return value, fluent kullanım veya container içinde kullanım gibi yerlerde patlayabilir. O yüzden gerçekten taşınması gerekiyorsa explicit move yazmak mantıklı.
Bir de deep copy tercih edilecekse copy assignment kısmında küçük bir exception-safety notu var: mevcut buf önce delete edilip sonra yeni buffer alınıyor. buffer_new / buffer_write tarafında başarısızlık ihtimali varsa nesne yarım state’te kalabilir. Daha güvenli yaklaşım önce yeni buffer’ı oluşturup yazmak, her şey başarılı olduktan sonra eski buffer’ı bırakmak veya copy-and-swap tarzı gitmek olur.
Özetle TEMP_BUFFER için bence en doğru çözüm:
TEMP_BUFFER(const TEMP_BUFFER& = delete;<br>TEMP_BUFFER& operator=(const TEMP_BUFFER& = delete;<br><br>TEMP_BUFFER(TEMP_BUFFER&& noexcept;<br>TEMP_BUFFER& operator=(TEMP_BUFFER&& noexcept;<br>
Uzun vadede de raw LPBUFFER sahipliğini doğrudan sınıfta taşımak yerine custom deleter’lı unique_ptr benzeri bir handle/wrapper yazmak daha temiz olur. Böylece “bu kaynak kime ait, kim release edecek, kopyalanabilir mi?” soruları koddan daha net okunur.
Kısacası sorun hayati olmasa bile tespit doğru: kaynak yöneten sınıflarda compiler’ın ürettiği copy special member’lara güvenmek genelde saatli bomba.
Eline sağlık, tespit bence doğru. TEMP_BUFFER burada value-semantic bir tip gibi değil, ownership taşıyan geçici bir RAII wrapper gibi davranıyor. Bu yüzden benim de ilk tercihim deep copy yazmak değil, copy ctor ve copy assignment’ı tamamen kapatmak olurdu.
TEMP_BUFFER(const TEMP_BUFFER&
= delete;<br>TEMP_BUFFER& operator=(const TEMP_BUFFER& = delete;<br>Çünkü deep copy yazınca sınıfa “kopyalanabilir ve aynı state’i korur” anlamı yüklenmiş oluyor. Ama senin de not düştüğün gibi read point, flag/state vb. her şey birebir taşınmıyorsa bu sefer başka bir yanıltıcı davranış doğabilir. TEMP_BUFFER paket oluşturma tarafında geçici buffer gibi kullanılıyorsa copy-delete çok daha net ve güvenli.
Move tarafı için de uyarın yerinde. User-declared destructor olduğu için move ctor / move assignment otomatik gelmiyor. Copy’leri delete edince sınıf move da edilemiyorsa, ileride std::move, return value, fluent kullanım veya container içinde kullanım gibi yerlerde patlayabilir. O yüzden gerçekten taşınması gerekiyorsa explicit move yazmak mantıklı.
Bir de deep copy tercih edilecekse copy assignment kısmında küçük bir exception-safety notu var: mevcut buf önce delete edilip sonra yeni buffer alınıyor. buffer_new / buffer_write tarafında başarısızlık ihtimali varsa nesne yarım state’te kalabilir. Daha güvenli yaklaşım önce yeni buffer’ı oluşturup yazmak, her şey başarılı olduktan sonra eski buffer’ı bırakmak veya copy-and-swap tarzı gitmek olur.
Özetle TEMP_BUFFER için bence en doğru çözüm:
TEMP_BUFFER(const TEMP_BUFFER&
= delete;<br>TEMP_BUFFER& operator=(const TEMP_BUFFER& = delete;<br><br>TEMP_BUFFER(TEMP_BUFFER&& noexcept;<br>TEMP_BUFFER& operator=(TEMP_BUFFER&& noexcept;<br>Uzun vadede de raw LPBUFFER sahipliğini doğrudan sınıfta taşımak yerine custom deleter’lı unique_ptr benzeri bir handle/wrapper yazmak daha temiz olur. Böylece “bu kaynak kime ait, kim release edecek, kopyalanabilir mi?” soruları koddan daha net okunur.
Kısacası sorun hayati olmasa bile tespit doğru: kaynak yöneten sınıflarda compiler’ın ürettiği copy special member’lara güvenmek genelde saatli bomba.
benim kartın limiti dolmuş o yüzden kendi bilgimi kullanarak yorum yapmam gerekiyor. kendi bilgimle de uzun bir inceleme yapmaya üşeniyorum. zaten bu konu hakkında çokta bilgi sahibi değilim o yüzden elimden sadece teşekkür etmek geliyor. @Larry Watterson eline sağlık teşekkürler.sıra bende
Eline sağlık, tespit bence doğru. TEMP_BUFFER burada value-semantic bir tip gibi değil, ownership taşıyan geçici bir RAII wrapper gibi davranıyor. Bu yüzden benim de ilk tercihim deep copy yazmak değil, copy ctor ve copy assignment’ı tamamen kapatmak olurdu.
TEMP_BUFFER(const TEMP_BUFFER&
Çünkü deep copy yazınca sınıfa “kopyalanabilir ve aynı state’i korur” anlamı yüklenmiş oluyor. Ama senin de not düştüğün gibi read point, flag/state vb. her şey birebir taşınmıyorsa bu sefer başka bir yanıltıcı davranış doğabilir. TEMP_BUFFER paket oluşturma tarafında geçici buffer gibi kullanılıyorsa copy-delete çok daha net ve güvenli.
Move tarafı için de uyarın yerinde. User-declared destructor olduğu için move ctor / move assignment otomatik gelmiyor. Copy’leri delete edince sınıf move da edilemiyorsa, ileride std::move, return value, fluent kullanım veya container içinde kullanım gibi yerlerde patlayabilir. O yüzden gerçekten taşınması gerekiyorsa explicit move yazmak mantıklı.
Bir de deep copy tercih edilecekse copy assignment kısmında küçük bir exception-safety notu var: mevcut buf önce delete edilip sonra yeni buffer alınıyor. buffer_new / buffer_write tarafında başarısızlık ihtimali varsa nesne yarım state’te kalabilir. Daha güvenli yaklaşım önce yeni buffer’ı oluşturup yazmak, her şey başarılı olduktan sonra eski buffer’ı bırakmak veya copy-and-swap tarzı gitmek olur.
Özetle TEMP_BUFFER için bence en doğru çözüm:
TEMP_BUFFER(const TEMP_BUFFER&
Uzun vadede de raw LPBUFFER sahipliğini doğrudan sınıfta taşımak yerine custom deleter’lı unique_ptr benzeri bir handle/wrapper yazmak daha temiz olur. Böylece “bu kaynak kime ait, kim release edecek, kopyalanabilir mi?” soruları koddan daha net okunur.
Kısacası sorun hayati olmasa bile tespit doğru: kaynak yöneten sınıflarda compiler’ın ürettiği copy special member’lara güvenmek genelde saatli bomba.
Konu Sahibi
Konu Sahibi
Custom deleter için duruma göre stateless bir lambda veya functor yazılabilirse maliyet olmayacağından(deleter state taşırsa veya function pointer kullanılırsa boyut büyür) olabilir, tasarım açısından ve prod'da pek tercih ettiğim bir yöntem değil ama metin2 için olabilir, neden olmasın..sıra bende
Eline sağlık, tespit bence doğru. TEMP_BUFFER burada value-semantic bir tip gibi değil, ownership taşıyan geçici bir RAII wrapper gibi davranıyor. Bu yüzden benim de ilk tercihim deep copy yazmak değil, copy ctor ve copy assignment’ı tamamen kapatmak olurdu.
TEMP_BUFFER(const TEMP_BUFFER&
Çünkü deep copy yazınca sınıfa “kopyalanabilir ve aynı state’i korur” anlamı yüklenmiş oluyor. Ama senin de not düştüğün gibi read point, flag/state vb. her şey birebir taşınmıyorsa bu sefer başka bir yanıltıcı davranış doğabilir. TEMP_BUFFER paket oluşturma tarafında geçici buffer gibi kullanılıyorsa copy-delete çok daha net ve güvenli.
Move tarafı için de uyarın yerinde. User-declared destructor olduğu için move ctor / move assignment otomatik gelmiyor. Copy’leri delete edince sınıf move da edilemiyorsa, ileride std::move, return value, fluent kullanım veya container içinde kullanım gibi yerlerde patlayabilir. O yüzden gerçekten taşınması gerekiyorsa explicit move yazmak mantıklı.
Bir de deep copy tercih edilecekse copy assignment kısmında küçük bir exception-safety notu var: mevcut buf önce delete edilip sonra yeni buffer alınıyor. buffer_new / buffer_write tarafında başarısızlık ihtimali varsa nesne yarım state’te kalabilir. Daha güvenli yaklaşım önce yeni buffer’ı oluşturup yazmak, her şey başarılı olduktan sonra eski buffer’ı bırakmak veya copy-and-swap tarzı gitmek olur.
Özetle TEMP_BUFFER için bence en doğru çözüm:
TEMP_BUFFER(const TEMP_BUFFER&
Uzun vadede de raw LPBUFFER sahipliğini doğrudan sınıfta taşımak yerine custom deleter’lı unique_ptr benzeri bir handle/wrapper yazmak daha temiz olur. Böylece “bu kaynak kime ait, kim release edecek, kopyalanabilir mi?” soruları koddan daha net okunur.
Kısacası sorun hayati olmasa bile tespit doğru: kaynak yöneten sınıflarda compiler’ın ürettiği copy special member’lara güvenmek genelde saatli bomba.
copy-swap idiom evet bir üstteki yorumda yazmıştım, konuda belirtmeyi atlamışım, yorum için teşekkürler
Şu an konuyu görüntüleyenler (Toplam : 4, Üye: 1, Misafir: 3)
Benzer konular
