Initialization of variables. Three valid methods.
c-like: int x = 0; // C
constructor initialization: int x(0); // C++
uniform initialisation: int x{0}; // C++11
I propose to progressively move to uniform initialisation. Much clearer.
Modernisation: Discussions
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
-
- Posts: 176
- Joined: Wed Mar 09, 2022 3:15 am
- Location: Oz
Re: Modernisation: Discussions
First I mentally objected, as I find the C-like initialisation especially for simple types easier to read. It looks more familiar.
But after reading this: GotW #1 Solution: Variable Initialization – or Is It? I agree with uniform initialization.
But after reading this: GotW #1 Solution: Variable Initialization – or Is It? I agree with uniform initialization.
Re: Modernisation: Discussions
I like this kind of topics. As non programmer i learn quite often a bit of background what makes it more easy when i read FC source!
Re: Modernisation: Discussions
Why does a pure C++ workbench needs an Init.py file? Respectively an InitGui.py file for the Gun part? Why the detour in using Python, instead of staying within C++ and only using Python for Python WBs?
I'm trying to understand the FC source and the decision behind some of these architectural code structures. Yet I could not find a satisfactory explanation for this concept. The search function in the forum wasn't helpful either.
## References
https://wiki.freecadweb.org/Workbench_creation
why need of init.py for c++ workbench site:forum.freecadweb.org
I'm trying to understand the FC source and the decision behind some of these architectural code structures. Yet I could not find a satisfactory explanation for this concept. The search function in the forum wasn't helpful either.
## References
https://wiki.freecadweb.org/Workbench_creation
Forum Post: How to start a new workbench with C++ ? https://forum.freecadweb.org/viewtopic. ... 901#p32901They can be coded in Python, in C++, or in a mix of both, which has the advantage to ally the speed of C++ to the flexibility of Python. In all cases, though, your workbench will be launched by a set of two Python files.
## Search termInitGui and init are called by FreeCAD at start-up. They announce the availability of Workbenches or import files types.
But the actual module only gets loaded if the user choose the workbench or try to import a support file type.
Then we actually load the module by the python mechanisms (import) and the DLL get loaded and python calls initRobot() and initRobotGui(). There the C++ side will be initialized...
why need of init.py for c++ workbench site:forum.freecadweb.org
- adrianinsaval
- Veteran
- Posts: 5553
- Joined: Thu Apr 05, 2018 5:15 pm
Re: Modernisation: Discussions
Is that not needed to be able to import the workbench in python and use it's functions? If you mean why we would want to import the workbench in python remember that freecad uses python for macros and the scripting capabilities are a central feature of freecad.
Re: Modernisation: Discussions
I understand that. But why using Python to import a pure C++ Workbench? I'd like to understand the reasoning behind this decision, and the tradeoffs therefore.adrianinsaval wrote: ↑Mon May 16, 2022 7:20 pm to be able to import the workbench in python and use it's functions?
Why not use C++ functionality to dynamically load a C++ workbench on runtime? This loaded WB would also have functionality exposed via a Python API (predefined via the App/Gui interfaces). I just don't understand the necessity to use a detour via Python to load a C++ WB.
Re: Modernisation: Discussions
A C++ workbench is just a set of GUI elements inside a dynamically loaded shared library. The library first must be loaded in order to use the workbench functionality.Why does a pure C++ workbench needs an Init.py file? Respectively an InitGui.py file for the Gun part?
Because one of the fundamental design principles in FreeCAD is lazy loading a library is not loaded automatically at program start but only on request. This allows it to start the application relatively quickly.
But if a library is not loaded a way must be implemented to offer some information about what it is capable of doing. This is done with the Init.py and InitGui.py files that are executed at program start. Usually the Init.py file contains code to register file extension the library is able to load, so they appear inside a file dialog. The InitGui.py file contains some meta information about the workbench, like name, icon, ... that you will see in the workbench combo box.
The libraries are also Python modules -- so called Python extension modules -- that extend Python with new functionality. This is needed for another basic design principle to make almost everything scriptable.Why the detour in using Python, instead of staying within C++ and only using Python for Python WBs?
Theoretically possible but you still need a hook function in order to load a library. Since Python implements a mechanism (that is written in C) exactly for this purpose there is no need to implement anything from scratch. All what a library needs to provide is a PyInit_name function where name is the file name (without suffix) of the library.Why not use C++ functionality to dynamically load a C++ workbench on runtime?