Ir al contenido



Foto

Data Module error 'External: SIGSEGV'

data module error

  • Por favor identifícate para responder
13 respuestas en este tema

#1 Gaston

Gaston

    Advanced Member

  • Miembros
  • PipPipPip
  • 70 mensajes

Escrito 07 noviembre 2016 - 01:48

Hola gente, nuevamente yo, me dispuse a hacer las cosas correctamente y utilizar los data modules y va todo bien hasta que compilo y me tira este hermoso error

 

ha lanzado una excepción de la clase 'External: SIGSEGV'.
 
 En archivo 'bancos.pas' en linea 46:
DataM.ZConnection1.Connect;
 
En tiempo de diseño, no tuve ningún problema en armar una DBGrid y conectar todo.
Lo que hice fue eliminar esa instrucción pero a la siguiente que es un simple ZQuery.Close también me tira el mismo error. Y Sí, he incluido la unidad uData que contiene el data model que nombré DataM, en todas las unidades, incluído el archivo del proyecto, ahí también está.
 
Alguna idea? Gracias.

  • 0

#2 Agustin Ortu

Agustin Ortu

    Advanced Member

  • Moderadores
  • PipPipPip
  • 775 mensajes
  • LocationArgentina

Escrito 07 noviembre 2016 - 04:14

Necesitamos ver el codigo y como configuraste los componentes


  • 0

#3 Delphius

Delphius

    Advanced Member

  • Administrador
  • 5.956 mensajes
  • LocationArgentina

Escrito 07 noviembre 2016 - 04:14

Hola Gaston, ¿Estuviste haciendo algún otro cambio en el proyecto?¿O instalaste algún componente nuevo? ¿Antes te estaba funcionando todo bien?

¿Te reporta ese error en ese proyecto en particular? ¿O te lo hace en otros? ¿Que versión de Zeos utilizas? ¿Que versión de Lazarus o de CodeTyphon tienes?

 

Recuerdo que el error SIGSEGV es un error a nivel IDE en el Debugger GDB, y no está en el uso de algún componentes en particular. Dicho error es muy general y no tiene una única causa de origen. Por lo tanto las soluciones son variadas.

 

Si admito que en alguna que otra ocasión me apareció, en mis primeros inicios con Lazarus/CodeTyphon, aunque no puedo asegurar que sea por un Connect de un ZConnection.

Hace tiempo que no he tenido problemas con Lazarus, ni con Zeos por lo que no tengo algo concreto para sospechar de alguna combinación IDE+Zeos.

Por lo pronto, si puedo aconsejar que uses Zeos 7.2.0-beta. Tuve dificultades con Zeos de otra versión.

Con la 7.2 beta no he tenido problemas. No al menos bajo CT 5.6. No me animo a asegurar de que una actualización de Lazarus/CT haga que se arregle, pero podría ser una posibilidad.

 

Si recuerdo que en la configuración de compilación para los proyectos se recomiendo usar Dwarf2 cuando se compila en Windows. Pero yo para mis "demos" de prueba y proyectos que llevo yo no tengo problemas con la configuración por defecto (automático -g).

 

Saludos,


  • 1

#4 Gaston

Gaston

    Advanced Member

  • Miembros
  • PipPipPip
  • 70 mensajes

Escrito 07 noviembre 2016 - 04:48

Es cierto omití algunos detalles, por eso ahora utilicé el campo Firma para que no se me olviden: Lazarus 1.6 FPC 3.0 en Linux Mint 17.2

Zeos 7.14 con SQLite pero no creo que venga por ahí el tema. Me explico más detalladamente ya que mientras tanto seguí investigando.

 

El problema radica en cuando intento acceder al Data Module desde el procedimiento Form.Create porque desde el resto de los procedimientos accedo sin ningún problema, recién terminé con el ABM sin problemas.

 

Delphius, este es un pequeño programa que me encargaron para llevar un libro bancos, el anterior fue una demo que ya finalizó y paralelamente estoy trabajando en la versión no demo que de momento estoy en la etapa de diseño, nada que ver con esto.


delphi
  1. procedure TfrmBancos.FormCreate(Sender: TObject);
  2. begin
  3. DataM.ZConnection1.Connect;
  4. DataM.ZQuery1.Close;
  5. end;

En realidad borré ese código y seguí con el ABM, pero me sería útil para verificar las conexiones con más código, desde ya, quería hacer lo mismo que hice en la demo donde no usé Data Module y funcionó muy bien ya que establece la conexión y librería de la DB según sea Windows o Linux.


delphi
  1. procedure TfrmCtaCte.FormCreate(Sender: TObject);
  2. begin
  3. if not(vDB) then
  4. begin
  5. ShowMessage('Base de Datos no conectada');
  6. exit;
  7. end;
  8. {$ifdef win32}
  9. if not(vLib) then
  10. begin
  11. ShowMessage('Librería de Base de Datos no encontrada');
  12. exit;
  13. end;
  14. {$endif}
  15.  
  16. ZConnection1.Database:=strDB;
  17. {$ifdef win32}
  18. ZConnection1.LibraryLocation:=strLib;
  19. {$endif}
  20.  
  21. ZConnection1.Connected:=true;
  22.  
  23. ZProv.SQL.Text:='SELECT * FROM prov ORDER BY nombre;';
  24. ZProv.Active:=true;
  25. ZQMoviInsu.SQL.Text:='SELECT * FROM movinsu ORDER BY idprod, idcompra;';
  26. ZQMoviInsu.Active:=true;
  27. ZQProd.SQL.Text:='SELECT * FROM prod ORDER BY desc;';
  28. ZQProd.Active:=true;
  29. end;

Como pueden ver ese código que funciona, no utiliza Data Module. Quise hacer algo parecido en un nuevo programa usando Data Module y me tira ese error.

 

Por ahí por algo que desconozco no puede hacerse lo mismo si se usa Data Module, raro, pero todo es posible.

 

Saludos.


  • 0

#5 Delphius

Delphius

    Advanced Member

  • Administrador
  • 5.956 mensajes
  • LocationArgentina

Escrito 07 noviembre 2016 - 04:50

Viendo el mensaje de error, dice que proviene desde el DataModule. En lo primero que pensaría es que en tu TDataModule tienes algo mal configurado o algún código que provoca el error hacia el debugger.

 

¿Tienes el TDataModule creado antes o después del form principal? En principio no debería ser problemas el orden a menos que por ejemplo si desde el form principal intentas acceder a un TDataModule no creado todavía va a darte un error (supuestamente un Access Violation).

 

Nos ayudaría mucho ver algo de código.

 

Para poder ayudarte vas a tener que darnos mucha información y detalles.

 

Saludos,


  • 1

#6 Delphius

Delphius

    Advanced Member

  • Administrador
  • 5.956 mensajes
  • LocationArgentina

Escrito 07 noviembre 2016 - 05:13

Ummm. ¿Que son vDB, vLib? ¿Funciones? ¿Variables? ¿En donde están declaradas? ¿En el mismo form? ¿En el TDataModule? He leido que en ocasiones el error External: SIGSEGV se da por un conflicto de variables...

 

Viendo que tu estás trabajando en multiplataforma es muy importante que nos aclares, ¿El error te lo da en Windows, o en Linux? Recuerdo que en otra ocasión nos comentaste que tu trabajas desde Linux y luego haces compilación para Windows. Tengo que admitir que Mint no lo conozco, asi que si resulta ser que el problema pudiera venir derivado de alguna particularidad con el SO (aunque tengo mis dudas que por ahí vaya el problema... aunque quien sabe... Lazarus ha tenido su historial de dificultades con su multiplataforma) no te sabría asesorar.

 

Yo de Zeos, puedo esperar cualquier cosa. Como te he comentado, tuve ciertas dificultades con otras versiones de Zeos. No descarto nada. Pero si es que venías comodamente trabajando ya antes con esta versión en otros proyectos no sería el principal problema.

 

Sería de mucha ayuda que nos puntualices y nos aclares bien separado que es lo que venías haciendo y que te estaba funcionando y que modificaste y que luego dejó de andar.

No termino de entender si al final te andó o no, si en el demo que haces te anda y en el otro no. Me confunde cual es cual.

 

Por lo que nos dices, yo pondría más el foco del problema en un conflicto Form->TDataModule. Alguna variable, método, o instrucción de mensaje de un lado a otro es lo que provoca el problema. Pero para aislarlo habrá que ver con lupa. Si dices que te lo da en el Create del form... en lo primero que pensaría es un error de orden de creación... que el DataModule no esté disponible al momento de crear el form. ¿Puedes fijarte en el código del .lpr como está el orden?

 

¿Lo tienes así?


delphi
  1. begin
  2. RequireDerivedFormResource:=True;
  3. Application.Initialize;
  4. Application.CreateForm(TForm1, Form1);
  5. Application.CreateForm(TDataModule1, DataModule1);
  6. Application.Run;
  7. end.

¿O el TDataModule primero y luego el form?

¿Dicho form es el principal? ¿O lo creas en tiempo de ejecución?

 

Lo mejor sería que nos indiques los pasos que fuiste realizando para poder reproducir tu caso lo más fielmente. Cuanto más precisiones nos puedas aportar ayudará.

 

Saludos,


  • 1

#7 Gaston

Gaston

    Advanced Member

  • Miembros
  • PipPipPip
  • 70 mensajes

Escrito 07 noviembre 2016 - 05:38

Delphius, el código que puse primero es el que tira el error, con Data Module; el otro código (el más largo) es el que no utiliza Data Module y funciona bien. Son dos programas distintos.

 

El código del actual, con el Data Module tirando error, lo tengo así:


delphi
  1. begin
  2. RequireDerivedFormResource:=True;
  3. Application.Initialize;
  4. Application.CreateForm(TForm1, Form1);
  5. Application.CreateForm(TfrmBancos, frmBancos);
  6. Application.CreateForm(TDataM, DataM);
  7. Application.Run;
  8. end.

Y éste es el código donde me tira el error:


delphi
  1. unit bancos;
  2.  
  3. {$mode objfpc}{$H+}
  4.  
  5. interface
  6.  
  7. uses
  8. Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs, DBGrids,
  9. StdCtrls, uData;
  10.  
  11. type
  12.  
  13. { TfrmBancos }
  14.  
  15. TfrmBancos = class(TForm)
  16. btnAgregar: TButton;
  17. btnModificar: TButton;
  18. btnBorrar: TButton;
  19. btnCerrar: TButton;
  20. btnAplica: TButton;
  21. DBGrid1: TDBGrid;
  22. edNombre: TEdit;
  23. edSucursal: TEdit;
  24. edCuenta: TEdit;
  25. edDetalle: TEdit;
  26. Label1: TLabel;
  27. Label2: TLabel;
  28. Label3: TLabel;
  29. Label4: TLabel;
  30. procedure btnBorrarClick(Sender: TObject);
  31. procedure btnCerrarClick(Sender: TObject);
  32. procedure btnAgregarClick(Sender: TObject);
  33. procedure btnModificarClick(Sender: TObject);
  34. procedure btnAplicaClick(Sender: TObject);
  35. procedure FormCreate(Sender: TObject);
  36. procedure BorraEdit;
  37. private
  38. { private declarations }
  39. public
  40. { public declarations }
  41. end;
  42.  
  43. var
  44. frmBancos: TfrmBancos;
  45.  
  46. implementation
  47.  
  48. {$R *.lfm}
  49.  
  50. { TfrmBancos }
  51.  
  52. procedure TfrmBancos.FormCreate(Sender: TObject);
  53. begin
  54. // DataM.ZConnBancos.Connect;
  55. // DataM.ZQBancos.Close;
  56. BorraEdit;
  57. btnAplica.Enabled:=false;
  58. end;
  59.  
  60. procedure TfrmBancos.btnAgregarClick(Sender: TObject);
  61. begin
  62. DataM.ZQBancos.Insert;
  63. DataM.ZQBancos.FieldByName('nombre').AsString:=edNombre.Text;
  64. DataM.ZQBancos.FieldByName('sucursal').AsString:=edSucursal.Text;
  65. DataM.ZQBancos.FieldByName('cuenta').AsString:=edCuenta.Text;
  66. DataM.ZQBancos.FieldByName('detalle').AsString:=edDetalle.Text;
  67. DataM.ZQBancos.Post;
  68. BorraEdit;
  69. end;
  70.  
  71. procedure TfrmBancos.btnModificarClick(Sender: TObject);
  72. begin
  73. edNombre.Text:=DataM.ZQBancos.FieldByName('nombre').AsString;
  74. edSucursal.Text:=DataM.ZQBancos.FieldByName('sucursal').AsString;
  75. edCuenta.Text:=DataM.ZQBancos.FieldByName('cuenta').AsString;
  76. edDetalle.Text:=DataM.ZQBancos.FieldByName('detalle').AsString;
  77. btnAplica.Enabled:=true;
  78. end;
  79.  
  80. procedure TfrmBancos.btnAplicaClick(Sender: TObject);
  81. begin
  82. DataM.ZQBancos.Edit;
  83. DataM.ZQBancos.FieldByName('nombre').AsString:=edNombre.Text;
  84. DataM.ZQBancos.FieldByName('sucursal').AsString:=edSucursal.Text;
  85. DataM.ZQBancos.FieldByName('cuenta').AsString:=edCuenta.Text;
  86. DataM.ZQBancos.FieldByName('detalle').AsString:=edDetalle.Text;
  87. DataM.ZQBancos.Post;
  88. BorraEdit;
  89. btnAplica.Enabled:=false;
  90. end;
  91.  
  92. procedure TfrmBancos.btnCerrarClick(Sender: TObject);
  93. begin
  94. Close;
  95. end;
  96.  
  97. procedure TfrmBancos.btnBorrarClick(Sender: TObject);
  98. var
  99. seguro:string;
  100. sino:TModalResult;
  101. begin
  102. seguro:='Confirma borrar el banco: '+DataM.ZQBancos.FieldByName('nombre').AsString+
  103. ' Si lo hace se borrarán todas las registraciones de dicho banco.';
  104. sino:=QuestionDlg('Confirma la operación?',seguro,
  105. mtCustom,[mrYes,'Sí, borrar', mrNo, 'No, regresar', 'IsDefault'],'');
  106. IF sino=mrYes then
  107. begin
  108. DataM.ZQBancos.Edit;
  109. DataM.ZQBancos.Delete;
  110. end
  111. ELSE
  112. exit;
  113. end;
  114.  
  115. procedure TfrmBancos.BorraEdit;
  116. begin
  117. edNombre.Text:='';
  118. edSucursal.Text:='';
  119. edCuenta.Text:='';
  120. edDetalle.Text:='';
  121. end;
  122.  
  123. end.

ZConnBancos es ZConnection y ZQBancos es ZQuery.

 

Esto funciona bien si le anulo las 2 primeras lineas a procedure TfrmBancos.FormCreate(Sender: TObject);

 

En el DataModule no tengo mucho código:


delphi
  1. unit uData;
  2.  
  3. {$mode objfpc}{$H+}
  4.  
  5. interface
  6.  
  7. uses
  8. Classes, SysUtils, db, FileUtil, ZConnection, ZDataset;
  9.  
  10. type
  11.  
  12. { TDataM }
  13.  
  14. TDataM = class(TDataModule)
  15. DSBancos: TDataSource;
  16. ZConnBancos: TZConnection;
  17. ZQBancos: TZQuery;
  18. private
  19. { private declarations }
  20. public
  21. { public declarations }
  22. end;
  23.  
  24. var
  25. DataM: TDataM;
  26.  
  27. implementation
  28.  
  29. {$R *.lfm}
  30.  
  31. end.


  • 0

#8 Delphius

Delphius

    Advanced Member

  • Administrador
  • 5.956 mensajes
  • LocationArgentina

Escrito 07 noviembre 2016 - 05:57

¿En que momento creas y/o visualizas al form frmBancos?

¿Desde el form1 también conectas?

 

En principio el orden no debería dar problemas. Pero viendo tu caso mi primer sospecha es que el DataModule todavía no ha sido creado al momento de crear el form frmDatos y éste intenta acceder a él. Si es que mi sospecha está en lo correcto, las instrucciones se realizan tan rápido y al estar el CreateForm() del frmDatos antes del CreateForm() del TDataM hay una violación de memoria al momento del OnCreate().

 

Es por ello que en Delphi (al menos en las versiones anteriores a D2006) es buena práctica (de hecho el compilador lo hace solito) tener el CreateForm() de los TDataModule ANTES que los forms que accedan a él.

 

Prueba alterando el orden: Proyecto -> Opciones del Proyecto -> Formularios. Ahí puedes establecer el orden de creación de tus forms y módulos de datos. Incluso puedes indicar si se deben crear automáticamente o simplemente ponerlos en disponibles (en este caso es responsabilidad tuya crearlos por código cuando son necesarios)

 

Saludos,


  • 1

#9 Gaston

Gaston

    Advanced Member

  • Miembros
  • PipPipPip
  • 70 mensajes

Escrito 07 noviembre 2016 - 06:09

Muchas gracias Delphius, efectivamente diste en la tecla, modifiqué el código siguiendo tu sugerencia y ahora funciona.


delphi
  1. begin
  2. RequireDerivedFormResource:=True;
  3. Application.Initialize;
  4. Application.CreateForm(TDataM, DataM);
  5. Application.CreateForm(TForm1, Form1);
  6. Application.CreateForm(TfrmBancos, frmBancos);
  7. // Application.CreateForm(TDataM, DataM);
  8. Application.Run;
  9. end.

Respecto a lo que preguntas, el frmBancos se llama desde Form1. Y no, desde el Form1 no conecto con el Data Module.

 

Aprovecho para preguntar si conviene, tratándose de un programa muy chico, tener todas las querys, dataset y reportes en un solo Data Module o conviene tener un Data Module por cada formulario?

 

Saludos.


  • 0

#10 Agustin Ortu

Agustin Ortu

    Advanced Member

  • Moderadores
  • PipPipPip
  • 775 mensajes
  • LocationArgentina

Escrito 07 noviembre 2016 - 06:14

No tiene nada que ver la velocidad de las instrucciones. El orden de los factores altera el producto :)

 

Esta accediendo al DataModule en el OnCreate del Form: 


delphi
  1. procedure TfrmBancos.FormCreate(Sender: TObject);
  2. begin
  3. // DataM.ZConnBancos.Connect;
  4. // DataM.ZQBancos.Close;
  5. BorraEdit;
  6. btnAplica.Enabled:=false;
  7. end;

Osea si sacamos todo lo que sea metodos y vemos todo el codigo como uno, queda a grandes rasgos, esto:


delphi
  1. Application.CreateForm(TForm1, Form1);
  2. // codigo del on create de TForm1
  3. Application.CreateForm(TfrmBancos, frmBancos);
  4. DataM.ZConnBancos.Connect; // oops, todavia no se creo DataM
  5. DataM.ZQBancos.Close;
  6. frmBancos.BorraEdit;
  7. frmBancos.btnAplica.Enabled := False;
  8. Application.CreateForm(TDataM, DataM);

Lo que me llama la atencion es que no se eleva una excepcion EAccessViolation


Editado por Agustin Ortu, 07 noviembre 2016 - 06:16 .

  • 1

#11 Delphius

Delphius

    Advanced Member

  • Administrador
  • 5.956 mensajes
  • LocationArgentina

Escrito 07 noviembre 2016 - 06:33

Muchas gracias Delphius, efectivamente diste en la tecla, modifiqué el código siguiendo tu sugerencia y ahora funciona.


delphi
  1. begin
  2. RequireDerivedFormResource:=True;
  3. Application.Initialize;
  4. Application.CreateForm(TDataM, DataM);
  5. Application.CreateForm(TForm1, Form1);
  6. Application.CreateForm(TfrmBancos, frmBancos);
  7. // Application.CreateForm(TDataM, DataM);
  8. Application.Run;
  9. end.

Respecto a lo que preguntas, el frmBancos se llama desde Form1. Y no, desde el Form1 no conecto con el Data Module.

 

Aprovecho para preguntar si conviene, tratándose de un programa muy chico, tener todas las querys, dataset y reportes en un solo Data Module o conviene tener un Data Module por cada formulario?

 

Saludos.

 

No tienes nada que agradecer.

Es un gusto poder ayudar.

 

Viendo tus experiencias con Linux y con multiplataforma quizá en un futuro podría pedirte algunos consejos. Es un tema que me interesa... aunque mi caso es el inverso: desde Windows hacia Linux.

 

Sobre lo de tener uno o varios módulos de datos mi respuesta es un DEPENDE. Para un proyecto chico yo no me complicaría la vida: un único módulo y a trabajar.

Ahora, cuando el proyecto es grande... y hay muchos datasets, conexiones, etc. lo mejor sería distribuirlos en varios. Y aquí juega mucho la creatividad y necesidades. Podría ser interesante crear los módulos por demanda (es decir, por código y cuando se requieran usarlos) ya que puede ayudar a trabajar únicamente con las funcionalidades según las necesidades. Por ejemplo, digamos que a un ERP lo tengo pensado hacer por módulos, un módulo de ABM para Facturación, otro para Proveedores, etc. De esta forma podría ser una buena opción tener módulos de datos para cada uno y un módulo de datos principal que se encargue de tener los elementos comunes a todos y centralice la conexión.

 

 

 

No tiene nada que ver la velocidad de las instrucciones. El orden de los factores altera el producto :)

 

Esta accediendo al DataModule en el OnCreate del Form: 


delphi
  1. procedure TfrmBancos.FormCreate(Sender: TObject);
  2. begin
  3. // DataM.ZConnBancos.Connect;
  4. // DataM.ZQBancos.Close;
  5. BorraEdit;
  6. btnAplica.Enabled:=false;
  7. end;

Osea si sacamos todo lo que sea metodos y vemos todo el codigo como uno, queda a grandes rasgos, esto:


delphi
  1. Application.CreateForm(TForm1, Form1);
  2. // codigo del on create de TForm1
  3. Application.CreateForm(TfrmBancos, frmBancos);
  4. DataM.ZConnBancos.Connect; // oops, todavia no se creo DataM
  5. DataM.ZQBancos.Close;
  6. frmBancos.BorraEdit;
  7. frmBancos.btnAplica.Enabled := False;
  8. Application.CreateForm(TDataM, DataM);

Lo que me llama la atencion es que no se eleva una excepcion EAccessViolation

 

Por cierta experiencia te puedo decir que en ocasiones la velocidad tiene que ver... Me ha pasado con Delphi 6 para un trabajo de Sistemas Expertos hace ya unos cuantos años, cuando todavía tenía menos panza y más pelo. :D

Estaba implementando un árbol y el algoritmo A* y tenia algunos New(variable) y luego un variable := algo y me daba errores de violación de acceso.

El código parecía correcto, compilaba muy bien... pero al probar la aplicación seguía apareciendo el error. En algún lado estaba el problema. Entonces hice una traza profunda, paso a paso, anotando direcciones de variables, etc. Todo iba bien... no había problemas.

Fuera del IDE, pum.

Volví a hacer traza y esta vez descubrí al culpable: efectivamente las instrucciones se ejecutaban tan rápido que un New() no daba tiempo para poder hacer uso de la variable. Creeme. Me vi obligado a introducir una espera de milisegundo entre un New() y el uso de la variable.

 

En este caso no. Pero en otros si.

Coincido en la rareza de que no arroje un EAcccessViolation. Pero bue... ¡is Lazarus! :D

 

Saludos,


  • 0

#12 Agustin Ortu

Agustin Ortu

    Advanced Member

  • Moderadores
  • PipPipPip
  • 775 mensajes
  • LocationArgentina

Escrito 07 noviembre 2016 - 07:13

Creo que lo que comentas es una falla del manejador de memoria, que por lo que he leído, el de Borland dejaba bastante que desear y tenía fallas severas

Hoy por hoy lo que comentas creo que ya no pasa o no debería pasar..a menos que se use programación multi hilo pero eso es otro cantar

Lo de la excepción, si Free Pascal lo maneja igual que Delphi, si la unidad SysUtils no llega a inicializar, no hay quien capture y translade los errores del sistema a excepciones
  • 0

#13 Delphius

Delphius

    Advanced Member

  • Administrador
  • 5.956 mensajes
  • LocationArgentina

Escrito 07 noviembre 2016 - 07:36

Creo que lo que comentas es una falla del manejador de memoria, que por lo que he leído, el de Borland dejaba bastante que desear y tenía fallas severas

Hoy por hoy lo que comentas creo que ya no pasa o no debería pasar..a menos que se use programación multi hilo pero eso es otro cantar

Lo de la excepción, si Free Pascal lo maneja igual que Delphi, si la unidad SysUtils no llega a inicializar, no hay quien capture y translade los errores del sistema a excepciones

 

Yo había "escuchado" todo lo contrario: que el manejador de memoria de Delphi es de los mejores. Y eso que no cuenta con recolección de basura.

Ha decir verdad, esa fue la única vez que tuve un problema así. Y me pareció rarísimo. Aunque tampoco es tuve muchas otras oportunidades de implementar un TAD y/o volver a jugar con punteros. En lo posible, evitar jugar con ellos.

Yo había llegado a la conclusión de que posiblemente ciertas optimizaciones del compilador pudieran haber jugado, y/o que el código ensamblador producido es lo suficientemente rápido como para ganarle al acceso de la memoria reservada (y eso que lo que estaba reservado no era una gran estructura... era apenas unos nodos con las variables/punteros)

 

En multi-hilos ahí si que hay que cuidar bien la cosa.

Desconozco como es internamente y profundamente el manejo de las excepciones de Lazarus y FreePascal. Estimo que no debe diferir demasiado al de Delphi.

 

Saludos,


  • 1

#14 Gaston

Gaston

    Advanced Member

  • Miembros
  • PipPipPip
  • 70 mensajes

Escrito 07 noviembre 2016 - 08:10

 

Viendo tus experiencias con Linux y con multiplataforma quizá en un futuro podría pedirte algunos consejos. Es un tema que me interesa... aunque mi caso es el inverso: desde Windows hacia Linux.

 

Con todo gusto, te comento que además de Pascal, el tema multiplataforma, fue un factor determinante a la hora de elegir Lazarus. La verdad me sorprende lo bien que funciona, ya que con algunos ajustes, he logrado tener exactamente el mismo código para ambos SO. Eso así, hay detalles que funcionan en un SO y en otro no, y viceversa. Por ejemplo, el color de las letras de un botón me funciona en Linux y no en Windows, en la tabulación, en Linux no se marcan los botones, en Windows sí. Igual seguro es solucionable, pero como son cosas mínimas, lo dejo para más adelante.

 

Saludos.


  • 2





Etiquetado también con una o más de estas palabras: data module, error