I just had a VERY quick look at your latest code submission. A couple of comments:
E_Boolean type
enum E_Boolean {
ETRUE, EFALSE, ENULL
};
Really?
Firstly this is reinventing the wheel as there are already boolean classes. Secondly, if you assign ETRUE to a variable then the variable will enumerate to false in a logical test. That is to say:
E_Boolean flag = ETRUE;
...
if(flag) printf("Hello world!\n");
If this code is executed, nothing will be printed.
Logging
I was about to make a post here about this. We need a consistent logging interface. We do NOT want each module, library, program implementing its own logging mechanism.
Such a class needs to handle multiple log levels (FATAL, ERROR, WARNING, INFORMATION as a minimum). It needs to log to file, especially for daemon/server code, but generally anyway. Executable programs can still output messages to stderr or popup windows for immediate user attention, but I am talking about diagnostic logging here.
File structure
I am currently working on a Wiki article that will meet your approval regarding file structure. Once you approve it I will re-structure all the files appropriately. However I really think it isn't helping that we are each still using our own file structures independantly of each other.
Documentation
Specifically in-file documentation, header comments etc. You write much more dedicated C++ code than me. My C++ code is basically C code organised into classes. I don't really get a good idea from looking at the new code as to what it does or is meant for. The documentation is thin on good old fashioned descriptive text even if it does have generally thorough documentation on everything. But it just isn't descriptive enough to someone who hasn't got a clue, like me.
I was about to make a post here about this. We need a consistent logging interface. We do NOT want each module, library, program implementing its own logging mechanism.
The "Business" LOG is for logging business activities (events concerning the user).
The "Design Insufficiency" Log (Detected Events that the code was not designed to handle. These events concerns the developer)
The "Development Trace" Log (Anything the developer chooses to inform about code execution).
The Log instance provides a polling interface for the application to implement a Log view. The provided Log View Form is for embarcadero RAD Studio XE so it is of no use to us in the Console environment. But It shows Log entries in Tabs (Business, Design Insufficiency, Trace and All).
Such a class needs to handle multiple log levels (FATAL, ERROR, WARNING, INFORMATION as a minimum). It needs to log to file, especially for daemon/server code, but generally anyway. Executable programs can still output messages to stderr or popup windows for immediate user attention, but I am talking about diagnostic logging here.
Feel free to add FATAL, ERROR, WARNING, INFORMATION to any of these logs if that is how you do it. For me, I have taken the view that it is better to avoid grading the Log when creating a Log entry. If an event is fatal, Error or Warning is mostly defined with what was going on when it happened, rather than where in the code it occurred. I will not make an Issue about this but you will not find me defining the entry as WARNING or ERROR. When applicable I will decide if the Log is about Business, about a "whole" in the Design or just a trace and the phrase the logged text with "Warning or Fatal" if I see the need for it.
The DarwinetRADLib uses the log engine internally so you may easily find how I use the macros.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have a habit to define dedicated types for dedicated data also when the new type does not add any complexity to the type (i.e. it is just a new name of an existing type). I do this for several purposes:
When you read the code the type informs you what the data is for (the design domain in which it lives)
I may later decide to change the underlying type. For example I may later decide that c_DataRepresentationFramework::t_raw_byte is not an unsigned char but an signed char.
It is really helpful when refactoring code. If I need to find what code is affected by c_DataRepresentationFramework::t_raw_byte (i.e affected by changes to algorithms in the DataRepresentationFramework) I may easily do so. I may search or I may undefined it and let the comoplier tell me where the code breaks. Searching for "unsigned char" simply tells me nothing :).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am currently working on a Wiki article that will meet your approval regarding file structure. Once you approve it I will re-structure all the files appropriately. However I really think it isn't helping that we are each still using our own file structures independently of each other.
I agree. The code should "compile" in the file structure it is placed when checked out from the repository.
I see you have added your code at the top level of the Software folder. I suggest we put common code in the common folder and the "build" files/scripts in sub-folder to the "Projects" folder.
"Projects" are closed file trees defining one output build. E.g. The POSIX MIV Console may be one "Product". The Project folder then contains a "build" sub-folder with the build scripts (project files for VS) and dedicated source in sub-folders. Subversion allows for "Externals" within a version controlled directory tree. "Externals" are folders with subversion contents from another URL. In this way we may place "Common" code as Externals in a Project tree. In effect the External code will be checked out as a sub-folder but the files in it is really from another place in the repository.
You may wonder why there is a "build" folder in the Project folder. The motivation is that this level may also contain "deploy", "install" and "help" folders. All part of the Project but not part of building the source.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We need to break that code out of the DarwinetRADLib (what is that anyway)? So we can use it more generically.
File structure:
I really don't understand how you see this working. For the time being I will move all my code down two levels into the Projects folder.
I don't understand your description of the "build" folder. I could understand if it was called "VS12" and contained the VS12 specific files only, while the generic source code was stored under a directory called "src" that was at the same level as "VS12", along with "deploy", "install", and so on. Which is basically what I proposed.
I suggest you update the Wiki, with good multi-level examples, and then maybe I will understand it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi.
I just had a VERY quick look at your latest code submission. A couple of comments:
E_Boolean type
enum E_Boolean {
ETRUE, EFALSE, ENULL
};
Really?
Firstly this is reinventing the wheel as there are already boolean classes. Secondly, if you assign ETRUE to a variable then the variable will enumerate to false in a logical test. That is to say:
E_Boolean flag = ETRUE;
...
if(flag) printf("Hello world!\n");
If this code is executed, nothing will be printed.
Logging
I was about to make a post here about this. We need a consistent logging interface. We do NOT want each module, library, program implementing its own logging mechanism.
Such a class needs to handle multiple log levels (FATAL, ERROR, WARNING, INFORMATION as a minimum). It needs to log to file, especially for daemon/server code, but generally anyway. Executable programs can still output messages to stderr or popup windows for immediate user attention, but I am talking about diagnostic logging here.
File structure
I am currently working on a Wiki article that will meet your approval regarding file structure. Once you approve it I will re-structure all the files appropriately. However I really think it isn't helping that we are each still using our own file structures independantly of each other.
Documentation
Specifically in-file documentation, header comments etc. You write much more dedicated C++ code than me. My C++ code is basically C code organised into classes. I don't really get a good idea from looking at the new code as to what it does or is meant for. The documentation is thin on good old fashioned descriptive text even if it does have generally thorough documentation on everything. But it just isn't descriptive enough to someone who hasn't got a clue, like me.
E.g.
typedef c_DataRepresentationFramework::t_raw_byte t_byte
How does this differ to uint8_t? Why are we defining yet another type for a byte when we already have:
unsigned char
uint8_t
c_DataRepresentationFramework::t_raw_byte
and others no doubt.
I'll try to read up in BerTlv, but I don't get much time or opportunity and there are still other higher priorities.
There is such a Logging framework in the "DarwinetRADLib". See https://sourceforge.net/p/darwinet/code/50/tree/trunk/Software/common/cpp/DarwinetRADLib/BusinessLogUnit.cpp. I have used this code for years in several projects. It defines three Logs (for different audiences). But all entries are saved into the same file. It also defines Macros to apply logging in the code (and enable/disable in debug and release versions)
The Log instance provides a polling interface for the application to implement a Log view. The provided Log View Form is for embarcadero RAD Studio XE so it is of no use to us in the Console environment. But It shows Log entries in Tabs (Business, Design Insufficiency, Trace and All).
Feel free to add FATAL, ERROR, WARNING, INFORMATION to any of these logs if that is how you do it. For me, I have taken the view that it is better to avoid grading the Log when creating a Log entry. If an event is fatal, Error or Warning is mostly defined with what was going on when it happened, rather than where in the code it occurred. I will not make an Issue about this but you will not find me defining the entry as WARNING or ERROR. When applicable I will decide if the Log is about Business, about a "whole" in the Design or just a trace and the phrase the logged text with "Warning or Fatal" if I see the need for it.
The DarwinetRADLib uses the log engine internally so you may easily find how I use the macros.
I have a habit to define dedicated types for dedicated data also when the new type does not add any complexity to the type (i.e. it is just a new name of an existing type). I do this for several purposes:
I agree. The code should "compile" in the file structure it is placed when checked out from the repository.
I see you have added your code at the top level of the Software folder. I suggest we put common code in the common folder and the "build" files/scripts in sub-folder to the "Projects" folder.
"Projects" are closed file trees defining one output build. E.g. The POSIX MIV Console may be one "Product". The Project folder then contains a "build" sub-folder with the build scripts (project files for VS) and dedicated source in sub-folders. Subversion allows for "Externals" within a version controlled directory tree. "Externals" are folders with subversion contents from another URL. In this way we may place "Common" code as Externals in a Project tree. In effect the External code will be checked out as a sub-folder but the files in it is really from another place in the repository.
For an example of this structure see https://sourceforge.net/p/darwinet/code/50/tree/trunk/Software/projects/MIVCosoleVS12/build/.
You may wonder why there is a "build" folder in the Project folder. The motivation is that this level may also contain "deploy", "install" and "help" folders. All part of the Project but not part of building the source.
Logging:
We need to break that code out of the DarwinetRADLib (what is that anyway)? So we can use it more generically.
File structure:
I really don't understand how you see this working. For the time being I will move all my code down two levels into the Projects folder.
I don't understand your description of the "build" folder. I could understand if it was called "VS12" and contained the VS12 specific files only, while the generic source code was stored under a directory called "src" that was at the same level as "VS12", along with "deploy", "install", and so on. Which is basically what I proposed.
I suggest you update the Wiki, with good multi-level examples, and then maybe I will understand it.