错误、漏洞、问题 - 页 2564

新评论
 
Igor Makanu:

?

这是一个奇怪的情况，班级以外的所有东西都在statichiqs上工作了很长时间。而我只是在大惊小怪....。只是为了好玩，你可以自己复制代码。

你看到一个对象实例吗？而且它存在于MQL中;)

SZZ：而且它存在于帮助层面......你对我有什么不满？

https://www.mql5.com/ru/docs/basis/oop/staticmembers

许可证


暗示

 
Andrey Barinov:

所有相同的规则 都适用于静态（私有、保护、公共），它们只是不需要创建对象。

一般情况下不是这样的：例如，在派生类中不能限制一个公共的statik

 
Andrey Barinov:



嗯...如何解释这种荒谬的情况...我建议你阅读管理员（开发者）的帖子，我给你看了他们写的帮助，你想从我这里得到什么，你的照片？

我不认为这是为什么，我阅读了论坛和帮助，并按照开发者的建议做了。如果你认为有必要，请写信给 "保护C++标准委员会"，给联合国...好吧，至少管理员在PM，如果你不能，但然后锁定开发人员的消息，并得到你的方式!

ZSY: 我不知为何能插入源代码而不是图片，为什么你的没有这样做？

int print(int value)
{  Print(value,":",__FUNCTION__); 
 return(value);
}
class A
{
private:
   static int        a1;
   static void       inc_a1(){a1++; Print("a1 = ", a1);}
protected:
   static int        a2;
public:
   static int        a3;

};
//+------------------------------------------------------------------+
static int A::a1 = print(1);
static int A::a2 = print(2);
static int A::a3 = print(3);

//+------------------------------------------------------------------+
void OnStart()
{

A::inc_a1();
A::inc_a1();
A::inc_a1();

}

2019.09.17 22:11:49.534 tst (EURUSD,H1) 1:print

2019.09.17 22:11:49.535 tst (EURUSD,H1) 2:print

2019.09.17 22:11:49.535 tst (EURUSD,H1) 3:print

2019.09.17 22:11:49.535 tst (EURUSD,H1) a1 = 2

2019.09.17 22:11:49.535 tst (EURUSD,H1) a1 = 3

2019.09.17 22:11:49.535 tst (EURUSD,H1) a1 = 4

ZS：情况相当滑稽，我想帮忙，现在我在制造借口....。为什么？- 好吧，为了真相而撞栏......踩着耙子....
 
Igor Makanu:

代码 中唯一的错误 是在私有方法的访问方面。这个错误是最近出现的。

 

ChartOpen函数 在服务中总是返回0。尽管图表本身打开了。

#property service

//int OnInit()
void OnStart()
  {
   long Otvet= ChartOpen(Symbol(),PERIOD_D1);
   Print("Otvet=",Otvet);

  // return(INIT_SUCCEEDED);
  }
 
fxsaber:

代码 中唯一的错误 是在私有方法的访问方面。这个错误是最近出现的。

我以为我忘记了什么，所以我重新阅读了C#中静态的行为方式https://metanit.com/sharp/tutorial/3.6.php

静态类成员对该类的所有对象都是通用的，因此你必须用其类名来指代它们。

注意，静态方法只能引用静态类成员。我们不能在静态方法中处理非静态方法、字段、属性。


在MQL中，静态方法在运行OnInit()之前被初始化，现在让我们讨论一下静态方法的全局可见性....。在MQL中静态的这种行为 - 如果你使用静态，这意味着我们不使用类的数据保护功能，我认为

这是个多大的错误？- 我说过，上下文操作的行为是由程序员决定的（上下文解决运算符是语言中最优先的运算符！）。)，而且编译器会正确地帮助--好吧，就像它发生的那样))

它是这样工作的吗？

class A
  {
private:
   static void              My_function()
     {
      Print("^_^");
     }
  };
  
A a;
void OnStart()
  {
   A::My_function();
   a.My_function();  // 'A::My_function' - cannot access private member function        
  }

总的来说，它做了工作


PS: 更新到2145--有静力学的代码表现相同，如果它保持这样半年，就会发现这是静力学的计划行为；)

UPD：记住，正如俚语所说的这一切叫做--肮脏的伎俩!)))- 在网络上寻找大量的例子，在这些例子中，这种行为被接受为一种语言标准，而它与制造商的特定编译器联系在一起。在Python中，eval()不是有效地破坏了线性代码的执行吗？- 嗯，有些是，有些不是，因为行为是不可预测的。


UPD: 在2145上查看我一个月前的问题https://www.mql5.com/ru/forum/320733#comment_12989063

https://www.mql5.com/ru/forum/320733#comment_12958594

void OnStart()
  {
   double x=100.0;
   f(x);
  }
//_______________________________________________________________________
void f(bool v)
  {
  }
//_______________________________________________________________________

什么都没有改变，在bool类型检查中，编译器没有学会写警告--这是非常不愉快的，我正在寻找我的代码中的错误，尽管我确信MQL编译器总是检查类型匹配。

 
Igor Makanu:

它有多大的错误呢？- 不管开发商怎么转，都会是这样的。

很明显，这个错误将被修复。

没有什么变化，编译器还没有学会在检查类型时如何在bool上写警告。

将指针和数字类型自动转换为bool是非常方便的。

 
Igor Makanu:

没有什么变化，在bool上检查类型时，编译器没有学会写警告--这是非常不愉快的，我已经在寻找我的代码中的错误，尽管我确信MQL编译器总是严格监控类型匹配。

在这个铸造过程中，没有数据损失。要么是0，要么不是0。

另一种情况是当double -> 任何整数类型（包括int32）时。

 
Slava:

有了这种铸造，就不会有数据损失。要么是0，要么不是0。

另一件事是当投掷双倍数->任何整数类型（包括int32）时

但反过来说呢？

我正在寻找我的代码中的一个错误

起初我写了一个测试，但首先使用了int ，然后我放弃了使用bool，但我没有修复整个代码，我不记得了，但它是这样的。

void OnStart()
{  int x=100.0;
   f(x); }
//_______________________________________________________________________
void f(int  v)  //так тестил
{
   if(v>0) v++;

}

//_______________________________________________________________________
void f(bool  v)  // потом решил, что мне нужен флаг, а ниже забыл исправить код
{
   if(v>0) v++;

}
//_______________________________________________________________________


我现在有点准备好了这样的行为，但我为什么要写这个......好吧，在if()中检查MQL条件--它严格控制类型吗？任何使用非布尔运算的行为都会发出警告？- 而以同样的方式，我在VS2017中用C#写的--我的示例代码不会编译，MQL也不会抛出警告。在我看来，对于那些刚接触MQL编程的人来说，这样的行为意味着一些惊喜。

 
fxsaber:

很明显，这个错误将被修复。

我不会争论，但我的观点是，当你通过静态以及使用上下文解析运算符离开类时，你不应该依赖来自编译器的控制。

也就是说，如果你写一个静态方法/字段或使用:::--不要依赖编译器。

1...255725582559256025612562256325642565256625672568256925702571...3184
新评论