Bon dia, Després de l'ultim e-mail he aparcat la feina que feia i aquest matí li he dedicat 15 minuts a fer una versió per la classe LogFile. A veure que us semblen les coses que hi he afegit. Se li podrien donar noves funcionalitats per a evitar de declarar-lo com a g_log i definir-lo coma a 'Singleton', però això no sé si t'interessa. He definit una nova funció WriteLog amb el mateix format del printf() per si vols simplificar el procés de generació de registres. Les funcions segures de Microsoft (acabades en '_s') no son de la API de Windows i no són compilables amb altres compiladors. Veig que s'han utilitzat les versions definides amb template<size_t>. Si les vols eliminar i que no aparegui el warning corresponent suposo que ja saps que només caldrà definir #define _CRT_SECURE_NO_WARNINGS en el stdafx.h. Salutacions Jordi Latorre Al 05/10/2012 9:20, En/na Jordi Latorre ha escrit:
Bon dia,
Al 04/10/2012 20:31, En/na Jordi Mas ha escrit:
Bona tarda,
Com que el projecte Catalanitzador ha crescut molt, i per a posar-me a treballar m'agradaria coneixer bé el codi d'en Jordi Mas he començat a preparar una llibreria 'libcatz' amb les classes originals convenientment modificades en les seves entranyes de manera que el codi sigui el màxim portable. A més, també he pogut veure que ha crescut molt
Quan et refereixes al màxim portable pots posar alguns exemples?
Això és deformació professional. Intentar que el codi s'ajusti al màxim a les llibreries ANSI C, ANSI C++, STL etc.. per si algun dia volem que pugui compilar amb qualsevol compilador.
Així, en el cas del fitxer de log proposo utilitzar _wfopen enlloc de CreateFile, fclose enlloc de CloseHandle, etc...
En el cas de les dates enlloc d'utilitzar el GetLocalTime proposo utilitzar _ftime64 i _localtime64.
Tots aquests canvis els he implementat i la generació del fitxer queda exactament com en el cas del Catalanitzador actual.
ràpid i no se li ha pogut dedicar molt temps a protegir el codi contra possibles errors del programador. Així que proposo:
- Utilitzar els namespaces per a contenir al màxim el codi i no equivocar-nos.
El tema dels namespaces em sembla bé. La confusió potencial que soluciona és bàsicament utilitzar una classe per altre. Una altra cosa que he vist en el codi és la utilització del '/using/'.
using namespace std;
A mi particularment no m'agrada donat que es perden les avantatges dels namespaces. Prefereixo escriure més, però tenir més control del que toco. Si cal escriure "std::cout << std::endl" el codi queda una mica més comprensible i evitem errors.
- Utilitzar més herències per a reduir el tamany dels fitxers.
Tens alguns exemples de fitxers que voldries reduir amb herències?
En treballar amb el fitxer LogFile, i per evitar tocar l'interface que utilitzes he fet el següent:
files::LogFile -> files::filebase files::ffile : accés al fitxer de log
- Protegir més les variables dins de les classes.
Pots posar alguns exemples? En el cas de 'HANDLE m_hLog' es pot escriure en ell des de diversos
En la classe filebase tinc un punter a un fitxer ffile que és el que realment accedeix al fitxer. ffile acaba estant com a private de filebase, de manera que queda protegit i al mateix temps el FILE* dins de ffile també és private protegint el seu valor i l'accés. La classe filebase únicament té sentit per a protegir la interface que estàs utilitzant. He tret algunes rutines protegides de Logfile per a posar-les dins de filebase. punts dins de la classe mateixa i en cap d'ells es comprova si el valor de la variable té un valor bo. De fet et disparará una excepció l'aplicació si no crides CreateLog un cop has creat l'objecte. Ja t'he comentat que estic molt pervertit pel meu món de programació, i potser no fa falta controlar tant el codi, encara que crec que pot ajudar.
Jordi, comprenc que a tot programador li 'fot' molt que toquin el propi codi. Què et sembla si t'envio una petita mostra?
No tinc vincles emocionals amb el codi. Qualsevol canvi em sembla bé que sigui una millora.
Caldria que les classes i el codi mantinguéssin un mateix Coding Standard.
- Una de les coses que m'agrada és el '_' que afegeixes davant de les rutines protegides i que utilitzaré a partir d'ara en els meus desenvolupaments futurs.
- He vist també que en alguns casos utilitzes 'm_' davant de variables de classe i en d'altres no. A mi m'agrada afegir '_' al final de la variable per a protegides i '__' (2 _) per a les privades.
- Respecte als if (...) una cosa que podries fer i que el MISRA C recomana és posar el valor de la constant abans per a que el compilador t'avisi si t'equivoques: (0 != variable) enlloc de (variable != 0). Això evitaria errors difícils de trobar com if(variable = 0) // ==
- A l'entrada de rutines caldria afegir comprovacions de validesa i de rang utilitzant 'asserts' per a que al "debugar" cantin els errors.
- Utilitzar el modificador 'const' per a variables d'entrada i no sortida.
- A la classe LogFile he afegit una rutina writeLog(const wchar_t* format, ...) similar al printf per a evitar la sobrecàrrega de Log(wchar_t*), Log(wchar_t*,wchar_t*), etc...
Atentament,
Jordi,
La referència està força bé.
Espero que les propostes t'agradin, no sóc ningú per a fer res sense el teu consentiment. Això em pot donar molta feina i crec que pot ajudar al manteniment i clarificació de tot el codi.
Atentament,
Jordi L.
_______________________________________________ Desenvolupament mailing list Desenvolupament@llistes.softcatala.org http://llistes.softcatala.org/mailman/listinfo/desenvolupament _______________________________________________ Codi de conducta: http://www.softcatala.org/wiki/Codi_de_conducta