On 11/6/12 5:59 PM, jan iversen wrote:
@andre:
I just saw one line in your mail, that I forgot to respond to....you look
for the interesting part of the code, the file tree scanner.
There are no tree scanning with the new concept, it is done by the makefile.
Each makefile (or build.lst) is extended with something like:
genLang: src1.hrc src2.xcd ....
genLang -m<module name> -t<target dir> $*
Thereby each single developer decides which files get scanned, and build
get rid of this big tree scanning.
So collecting the files to process is done by the makefile and passed
via $* ? Sounds reasonable.
But calling genLang for all files in one directory introduces a number
of sub processes, although not as much as before. And much better than
before.
Sorry that I forgot to mention that in my first mail.
Jan.
On 6 November 2012 16:12, jan iversen<jancasacon...@gmail.com> wrote:
HI
Thanks for your input, it is not too harsh, I prefer straight comments
than something I have to read several times to understand.
I will not disturb your session, but I have put some reasons/answers below.
rgds
Jan I.
On 6 November 2012 14:38, Andre Fischer<awf....@gmail.com> wrote:
On 11/4/12 1:55 PM, jan iversen wrote:
Hi.
I have finished the control part of the new localization tool, and
before I walk further down the line (writing/converting all the
translations parts) I would like to have checked if the code is ok in terms
of standard, readability and expectations (from other C++ programmers).
I hope one of the C++ programmers, can have a quick look at the code and
tell me:
- Are the code written in accordance with the AOO standards (I think so)
- Is it in general in accordance with the AOO writing style.
- C++ files usually have file extensions of .cxx and .hxx
- There are some conventions of naming variables like mnSomthing for a
numerical member variable.
I can live with you using a different naming scheme but would ask to
change the file extensions.
I will change the extensions, no problem...I use hungarian notation for
variables, and I know that some system require e.g. int variable to start
with a lower case "i", something I am not to much friend of, because it
gets very cluttered when you make your own classes.
We don't use full hungarian notation, just an m for member variables and
then and n for numbers, s for strings, r for references, p for pointers,
a for everything else. But I am a big friend of formatting your code as
you feel comfortable with. But try to keep it readable by others.
Eventually your code will have to be maintained by somebody else.
Of course, I would very much like to hear if there are non-efficient /
malicious code in there, but please remember this is only the control
skeleton, so there are a lot of code missing.
I only found one thing:
genConvert.cpp convert_gen::getConverter
- There are two if statements at the start of the method. The second
looks like it should be a "else if" instead.
UPS, corrected.
- The return at the bottom looks unreachable.
The return is actually just to please the compiler, it cannot be
reached...but try to remove the statement and you get errors.
Ah, I see.
But the main thing that I am not sure about is whether C++ is the right
language for this. I am not sure because I have not found the interesting
part of the program: how the file tree is traversed, how external tools are
called, or whether there are not external tools anymore.
If the main task of genLang is to traverse the file tree and call
external tools, then a script language like Perl might be better suited and
would speed up implementation a lot.
No, there will be no external tools...all will be embedded in genLang, I
am right now embedding transex3 (which is a lex grammar), each conversion
is done as its own class, making it easy to expand.
Localize_sl, spawns today different processes, written in C++, Lex, bash,
python and bash....that is not maintainable, making it with classes as one
program in C++ makes it easier to maintain.
I agree and I am glad that you are doing it this way. I also agree that
C++ is the right choice of language when all the external tools are
integrated.
I have done some speed test (based on some input I got on localize_sl). On
windows localize_sl takes about 2 minutes to complete "sw" directory,
mainly due to spawning a new process for each file. My preliminary test
makes me believe that genLang will do the same in less than 10 seconds.
I try to include a zip file with this mail, should I not succeed, then
please respond to the mail and I will sent it directly.
If the above sounds too harsh, then that is because I am currently
sitting in the BoF seesion and am trying to concentrate on two things at
the same time.
THANKS for taking time, have a nice session.
I have on the other hand been searching for unit test tools, it seems we
are not really using that....my biggest fear is to build something (of
course with high reuse of source) without being able to guarantee that the
output is identical to the old process.
Yes, using unit tests would be good. Don't be as lazy as the rest of us :-)
-Andre
MANY Thanks in advance for the help.
Jan.
