[fpc-devel] RTL / SysUtils / GetLocaleStr, GetLocaleChar
Hi, is there any reason, why GetLocaleStr and GetLocaleChar (unit SysUtils under Win32) are not published? wkr Peter. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc_ShortStr_To_WideStr
peter green wrote: Applied. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Friend" classes?
DrDiettrich wrote: > Florian Klaempfl wrote: > > >>C++ creates one monster module in this case as well. > > > I disagree. Neither the declarations (interface, header files) nor the > definitions (implementation, code modules) must reside in one file. How the sources are splitted doesn't matter. The compiler handles it as one file and creates one object module. The compiler even doesn't see that the files are splitted, the preprocessor concats everything. > C > header files can #include each other, and some more or less advanced > techniques can prevent multiple inclusion of the same header file. Pascal can do the same, see the fpc rtl: for easier handling they are splitted into multiple files. Units are a higher level concept than the include files of C++ but units can often but not necessarily reflect the include file structure. If you want 1:1 translations use include files in pascal as well. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Friend" classes?
Micha Nelissen wrote: > The real question is: was the design of the code ok ? Some dependencies cannot be removed by a redesign :-( In some cases interfaces instead of classes can help, because they don't need implementation in the same unit. But then the classes have to be implemented as well. IMO it's important to keep classes encapsulated in distinct units, so that no unintended interaction (use of private/protected members of other classes...) can occur, as is possible in a single unit. > Circular references makes code harder to understand. > Layers are easier to understand. I see no problem in understanding here? When two objects refer to each other, but the objects are not otherwise functionally related, they can be understood without knowing about the other one. It also should be possible to implement all these objects seaparately. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Friend" classes?
Florian Klaempfl wrote: > C++ creates one monster module in this case as well. I disagree. Neither the declarations (interface, header files) nor the definitions (implementation, code modules) must reside in one file. C header files can #include each other, and some more or less advanced techniques can prevent multiple inclusion of the same header file. > You could do the > same as in C++: split everything into include files. Pascal units aren't > 1:1 equivalent of C++ include files, if C++ libraries are done properly, > you can translate namespaces to pascal units. Just a question about the compilation in C/C++ and Pascal. A C compiler collects all required header files, prior to compiling a source module. The recompilation of the header files for every single code file is one reason for the slow C/C++ compilers. Namespaces IMO only have been introduced to reduce the size of the symbol tables, resulting from the many required header files. In modern Pascal, as I see it, the compilation of every unit is done in multiple steps, or passes, not in one pass as was possible with the single-unit original Pascal. In the first pass the Interface sections are compiled, of the unit itself and of all units in the Interface Uses list. The resulting compiled Interface section now can be used in the compilation of every other unit. In the second step the Implementation part of the unit is compiled, including the Implementation Uses list. Or how else can the Interface section of unit A use unit B, when the Implementation section of unit B uses unit A? Sure, compiler threads for every unit are a quasi-parallel solution, but then the threads become blocked between the compilation of the interface and implementation sections, effectively splitting the compilation process into 2 distinct steps. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
