Hatalar, hatalar, sorular - sayfa 2358

 
Ilya Malev :

Nesnenin sanal yöntemi olmasa bile, ona erişirken işaretçinin geçerliliğini kontrol etmek yine de gerekli olacaktır.

Genel olarak, bu belirsiz bir sorudur. Örneğin, C#'da böyle bir kontrol her zaman mevcuttur ve C++'da yalnızca gerektiğinde, bu da hız avantajı sağlar.

Sonuçta, nesnenin alanlarına erişimi olmayan bir yöntem çağrılırsa, işaretçiyi kontrol etmenin gerçekten bir anlamı yoktur. Özünde, böyle bir yöntem statik olana eşdeğerdir.

 
Alexey Navoykov :

Genel olarak, bu belirsiz bir sorudur. Örneğin, C#'da böyle bir kontrol her zaman mevcuttur ve C++'da yalnızca gerektiğinde, bu da hız avantajı sağlar.

Sonuçta, nesnenin alanlarına erişimi olmayan bir yöntem çağrılırsa, işaretçiyi kontrol etmenin gerçekten bir anlamı yoktur. Özünde, böyle bir yöntem statik olana eşdeğerdir.

Bir nesnenin hiç verisi olmayabilir, ancak bazı harici verilere özel türe bağlı bir şekilde erişme veya özel bir eylemi birlikte gerçekleştirme gibi tamamen farklı ve kritik davranışlar uygulayabilir. “Veri yokluğunda yöntemin statikle eşdeğerliği (% 100 sanal olmayan okuyun)” gibi bir yaklaşımı nasıl haklı çıkaracağımı bilmiyorum.

Yani, en azından bir işaretçi nesnesinin her zaman bir alanı vardır - bu onun türüdür. Çağrılan yöntemlerin adreslerini belirleyebilirsiniz. Başka neden OOP'ye ihtiyacınız olsun ki?

not Otomatik nesneler için, kişisel olarak herhangi bir davranış mantığına karşı değilim (çünkü onları neredeyse kullanmıyorum), ancak o zaman onların işaretçilere atanmasına izin vermenize gerek yok.
 

Ne yazık ki, tasarımlar için herkesi yanılttım.

B *b=a;
B b=a;

kopya yapıcısı değil, kopya operatörü çağrılır.
İkinci durumda, yapıcı B() çağrıldıktan sonra

Her durumda, önce analiz edeceğiz, sonra düzenleyeceğiz.

 

Oh, µl'de kopya oluşturucunun otomatik olarak üretildiği ortaya çıktı (hiç var olmadığını düşündüm, çünkü obj'yi (other_obj) Sınıflandıramazsınız, sadece = aracılığıyla). Ancak, aşağıdaki durumlarda neden oluşturulmaz:

 class Q
{
public :
   Q(Q&)= default ;   // нельзя
   Q( int ) {}       // из-за него копирующий конструктор исчез
};
 
pavlick_ :

Oh, µl'de kopya oluşturucunun otomatik olarak üretildiği ortaya çıktı (hiç var olmadığını düşündüm, çünkü obj'yi (other_obj) Sınıflandıramazsınız, sadece = aracılığıyla). Ancak, aşağıdaki durumlarda neden oluşturulmaz:

varsayılan ve silme desteklenmez

Varsayılan kopya oluşturucu şimdiye kadar yapılmış görünüyor.

Yalnızca kopyalama operatörü, yani. yapılar için:

CFoo foo=another_foo;

Önce varsayılan CFoo yapıcısı, ardından kopyalama operatörü çağrılır.

 
Ilyas :

kopya yapıcısı değil, kopya operatörü çağrılır.

Ama yine de bir hata çünkü. örtük kopya operatörü, tüm üst sınıflar için değil, yalnızca B sınıfı için oluşturulmalıdır. Onlar. bir nesne, iç kısımlarının kısmen değiştirilmesine izin vermemelidir.
 
Ilyas :

varsayılan ve silme desteklenmez

Evet, ancak yalnızca kullanıcı tanımlı bir kopya oluşturucu varsa, bir kopya oluşturucunun oluşturulmasını iptal etmeniz gerekir, değil mi? Ve herhangi bir kullanıcı değil.

 
Alexey Navoykov :
Onlar. bir nesne, iç kısımlarının kısmen değiştirilmesine izin vermemelidir.

Bu bir tür yapay kendini kısıtlama ... Hatta söyleyebilirim - düşünce darlığı

 class A {};
class B : public A {
public :
         void operator =( const A& ) {}
};

Sorun nedir?

Böyle bir tasarım buldum ... ve her şey çalışıyor ... iyi. Bu nedenle, Geliştiricilerin her şeyi olduğu gibi bırakmasını öneririm ... en azından ilgili operatörler/kurucular açıkça tanımlanmışsa

 
A100 :

Bu bir tür yapay kendini kısıtlama ... Hatta söyleyebilirim - düşünce darlığı

Sorun nedir?

Böyle bir tasarım buldum ... ve her şey çalışıyor ... iyi. Bu nedenle, Geliştiricilerin her şeyi olduğu gibi bırakmasını öneriyorum ... en azından ilgili operatörler açıkça tanımlanmışsa

İlk önce, her şeyin C++'da nasıl çalıştığını kontrol edin. Görünüşe göre kuralları "dar görüşlü insanlar" tarafından icat edildi.

Ve kendinizi dilin yanlış mimarisinden korumak için her seferinde tıkaçlarla çit çekmek ... Hayır, başlangıçta akıllıca yapmalısınız. dil demek istiyorum

 
Alexey Navoykov :

İlk önce, her şeyin C++'da nasıl çalıştığını kontrol edin. Görünüşe göre kuralları "dar görüşlü insanlar" tarafından icat edildi.

Ve kendinizi dilin yanlış mimarisinden korumak için her seferinde tıkaçlarla çit çekmek ... Hayır, başlangıçta akıllıca yapmalısınız. dil demek istiyorum

Özellikle sizin için https://www.mql5.com/ru/forum/1111/page2358#comment_10003995 dikkate alınarak tekrar kontrol ettim.

 #ifdef __cplusplus
#include "https://www.mql5.com/ru/forum/1111/page2358#comment_10003995"
void OnStart ()
{
        A a;
        B b;
        b = a;
}
#endif

sorun değil

Ошибки, баги, вопросы
Ошибки, баги, вопросы
  • 2018.12.24
  • www.mql5.com
Общее обсуждение: Ошибки, баги, вопросы