;this data parse in section '.data' readable writeable
@bb (its mean db 0)  name1,name2,name3,...,name100000
@bw(dw 0)  name1,name2,name3,...,name100000
@bd(dd 0)  name1,name2,name3,...,name100000
;this data parse in section '.bbs' readable writeable
@bb_ (rb 0)  V_name1,V_name2,..,V_name100000
@bw_ (rw 0)  V_name1,V_name2,..,V_name100000
@bd_ (rd 0)  V_name1,V_name2,..,V_name100000

;Procs or code using this variables
;Easy read and easy copy and paste this code ! All exist in one place !
@bb   nameA 'Text nameA',0
@bb   nameB 'Text nameB',0
@bd_  V_nameA,V_nameB  ;I write V_nameA because its abstraction and we know its bbs data 

mov eax,nameA
mov [V_nameA],eax
mov ecx,nameB
mov [V_nameB],ecx

@bb   nameC 'Text nameC',0
@bb   nameD 'Text nameD',0
@bd_  V_nameC,V_nameD  

mov eax,nameC
mov [V_nameC],eax
mov ecx,nameD
mov [V_nameD],ecx
    

P.S. Actually, allowing to declare variables in arbitrary places is one of the worst C/C++ features since it encourages mixing code and data which, in turn, leads to maintenance problems. Having your data defined in a single place (within a project, unit (not applicable to C/C++), function, method), on the contrary, lets you see clearly when it’s time to refactor your code.

DimonSoft wrote:

P.S. Actually, allowing to declare variables in arbitrary places is one of the worst C/C++ features since it encourages mixing code and data which, in turn, leads to maintenance problems. Having your data defined in a single place (within a project, unit (not applicable to C/C++), function, method), on the contrary, lets you see clearly when it’s time to refactor your code.

What do you mean by this? Also C/C++ have units, the .c or .cpp files themselves (they're called translation units), but idk what you have in mind.

DimonSoft интересно.
Натолкнул на мысль что иногда реально удобнее не описывать дату и отдельно каждую переменную(присваивая им имена), а выделить через WinAPI кусок памяти(например на 64 кб) и работать с ним как с массивом.

Удобно тем что разные проекты через WinAPI выделяют кусок памяти.
А когда я совмещу их в месте то каждый выделит свои участки памяти и не перебъет чужие выделения.
Что более проще в реализации, так же меньще проблем и писанины.

Compare this to C/C++ where you have your typical unit consist of two files (header and code) and you’d better not put variable declaration inside header file unless the declaration is marked with extern which basically means it is not a variable declaration but a reference to a variable that is declared somewhere else. Having same identifiers exported from multiple units means you’re stuck with renaming them since linker knows little to nothing about scopes. You can fake this with namespaces in C++ but that is basically a hack.

mov eax, variable_label    

variable_label db 5    

void foo();    

What I’m talking about is that it is quite a bold generalization to use the word “unit” for a set of rules to distribute declrations and definitions throughout multiple files plus a specific means of passing only some of them to the compiler, then passing object files generated to the linker. The only way I see to do that is to never have seen anything better and more comfortable.

Preprocessor has initially been a separate tool, and after it had its job done all we got was a set of files containing “unit” contents plus all the declarations and inline definitions (thanks for bringing the right terms here) from other “units”.

Then compiler and linker would work one after another to remove the unnecessary junk caused by blindly including the whole header file multiple times (leading to processing the declarations multiple times, once for each inclusion). The fact that preprocessor is usually integrated into compiler these days doesn’t change the concept.

As I’ve already started comparing it to Delphi, I’ll go on this way. Delphi provides equivalents for all the #include, #ifdef and #define stuff but noone would ever want to use them for splitting their project into units.

Because inclusion is not unit support. Having initialization and finalization sections for units with well-defined order of execution, avoiding multiple passes over the same piece of code leading to significant increase in building speed, being able to share your unit in compiled form without any sources (say, for a shareware library of controls or algorithms), choosing between same-named identifiers from multiple units no matter how they’re written, etc.—this stuff (off the top of my head) can hardly be achieved with the rudimentary way C/C++ emulate units. All that costs is that the language is aware of the concept of unit.

Turbo Pascal introduced units in version four (1987 or such). So yes, before that, you had to use non-standard {$include}. Extended Pascal (ISO 10206) had modules circa 1988, but that was unpopular. Even Modula-2 had modules (obviously) since its inception circa 1979. Of course, Oberon combined definition and implementation into one file with '*' export marker, for better simplicity (and to avoid repeating text, thus always keeping two files in sync, etc).

I think DimonSoft would agree with me.