Warning! - page 3

[nicholish en]

roshjardine:
this is MQL

This is a MQL BUG!

https://www.mql5.com/en/docs/basis/namespace

[Ehsan]

roshjardine:
we are not discussing c++,python,java,c# and so on here.. and i am not interested in programming language debate..this is MQL

What we are talking about is a simple rule. In MQL all of the concepts come from C++ so you can use it as a verifying tool.

[Ehsan]

Now let's wrap up

The compiler should compiles the following codes without any warnings or errors.

MQL inserts all included libraries to the main file which is the source of many complexities and errors.

#include <Trade/Trade.mqh>

input int fmt = 1;
int res; 

#include <Trade/Trade.mqh>

namespace MT
{
   input int fmt = 1;
   int res;
} 

int res = 0;

namespace MT 
{
   bool res = false;
}

When something is wrong, it's wrong. I don't care best practices right now. The above codes can be simply rewritten to working codes which I'm doing for 2 years and wondering why MQL team won't fix these problems.

[nicholish en]

Ehsan Tarakemeh:
Now let's wrap up

The compiler should compiles the following codes without any warnings or errors.

MQL inserts all included libraries to the main file which is the source of many complexities and errors.

When something is wrong, it's wrong. I don't care best practices right now. The above codes can be simply rewritten to working codes which I'm doing for 2 years and wondering why MQL team leave these problems live till now.

The namespace implementation is definitely broken and doesn't work as described in the documentation. If you want to make use of globals in its currently broken state then I can confirm that you won't have any conflicts with the standard library if you define your global variables with a "g_" prefix. It's both a programming best practice and a practical fix for your specific errors. 

[Ehsan]

nicholish en:

The namespace implementation is definitely broken and doesn't work as described in the documentation. If you want to make use of globals in its currently broken state then I can confirm that you won't have any conflicts with the standard library if you name your global variables with a "g_" prefix. It's both a programming best practice and a practical fix for your specific errors. 

Okay "g_" prefix?

I'm using a library that has functions with local variables prefixed with "g_" and I don't want to touch the library. Now should I add another "g_g_" to my global variables?

When something is wrong, it's always wrong.

[nicholish en]

Ehsan Tarakemeh:

Okay "g_" prefix?

I'm using a library that has functions with local variables prefixed with "g_" and I don't want to touch the library. Now should I add another "g_g_" to my global variables?

When something is wrong, it's always wrong.

Then use a class as a namespace. At least it will "work".

#include <trade/trade.mqh>

class global {
   public:
   static int fmt;
};
int global::fmt = 0;

void OnStart() {
   global::fmt = 10;
   Print(global::fmt);
}

[Sardion Maranatha]

nicholish en:

This is a MQL BUG!

https://www.mql5.com/en/docs/basis/namespace

take it easy...my understanding is this below regardless the namespace block, so long as it's put outside function description, it will be part of the global  if the library is going to be included in the file where the namespace is set..but the global value of res will not affect the value of res inside the namespace block

Global Variables

Global variables are created by placing their declarations outside function descriptions. Global variables are defined at the same level as functions, i.e., they are not local in any block.

i could be wrong but MQL guys can answer this precisely. I don't think it's a bug in my opinion, you could have your opinion but i am not interested to find who's right, we are all entitled to have different view

//--- hide it somewhere else from the compiler
extern int res = 0;

namespace IsitBug
{
   namespace One 
   {
      int res;
   
      int returnres()
      {
         res = 10;
         return(res);
      }
   }
   namespace Two
   {
      int res;
      int returnres()
      {
         res = 11;
         return(res);
      }
   }
   namespace Three
   {
      class A
      {
         bool res;
         public:
         bool boolres()
         {
            res = false;
            return(res);     
         }
      };
   
   }
   
   namespace Four
   {
      #include <TestOne.mqh>
   }
   
}
int OnInit()
  {


   Print(res);
   Print(IsitBug::One::returnres());
   Print(IsitBug::Two::returnres());
   IsitBug::Three::A a;
   Print(a.boolres());
   Print(IsitBug::Four::getres());
   res = IsitBug::One::returnres() + 100;
   Print("res is ",IntegerToString(res));
   
   return(INIT_SUCCEEDED);
  }

[nicholish en]

roshjardine:

 I don't think it's a bug in my opinion, you could have your opinion but i am not interested to find who's right, we are all entitled to have different view

I consider it a bug when the operation of a feature in practice performs inconsistently and contrary to its documentation. 

Namespaces are used to arrange a code in the form of logical groups and to avoid name conflicts that may occur when several libraries are used in a program. In such cases, each library can be declared in its namespace to explicitly access the necessary functions and classes of each library.

The only way this (your code with namespace) is NOT a bug is if the MQL maintainers intended to have namespaces that don't respect scope and than also proceeded to incorrectly translate ru to en in the docs. In which case the docs should read something like, "the keyword 'namespace' is reserved for future implementation, but does not respect proper scope at this time."

The aforementioned scenario is so highly unlikely that I feel confident in my assumption that namespace is a bugged-feature.  

[Sardion Maranatha]

nicholish en:

I consider it a bug when the operation of a feature in practice performs inconsistently and contrary to its documentation. 

The only way this (your code with namespace) is NOT a bug is if the MQL maintainers intended to have namespaces that don't respect scope and than also proceeded to incorrectly translate ru to en in the docs. In which case the docs should read something like, "the keyword 'namespace' is reserved for future implementation, but does not respect proper scope at this time."

The aforementioned scenario is so highly unlikely that I feel confident in my assumption that namespace is a bugged-feature.  

fair enough, i respect your view. thanks for additional insights

[Soewono Effendi]

Ehsan Tarakemeh:

Why do you bet? I won the bet.

A global variable shouldn't be accessed by an included file and that warning is because the compiler does a nasty thing in the first place. How should I explain this so everyone stop telling me ...?

I explained why this kind of name managing is not good for big projects.

I bet you never bother to understand what I'm talking about.
I bet every experienced compiler designer will agree with me.   

>> Understand what I'm talking about then tell me "know your tool then your experiences count."

That's your assumption.

Refer to https://www.mql5.com/en/docs/basis/preprosessor/include and you'll read following:
" The preprocessor replaces the line #include <file_name> with the content of the file ..."

"#include" is a simple "text replacement".

As I said, know your tool not your "wish tool".