Hola Fernando:
Ya los de VB ja-ja-ja-ja, hubieran querido tener algo como esto que tenemos en VFP.
Tenemos que tener en cuenta que en este sentido VFP lo hace terriblemente bien y extremadamente sencillo, cosa que es de envidiar, por muchos.
VB de esto tiene poco (salvo evaluaciones numéricas), por no decir nada ya que no me atrevo a afirmarlo con voz muy alta!!!!, por comentar he visto desarrollos de VB que han aplicado DLL en C, para poder llegar a tal funcionalidad y realizar cosas que nosotros podemos hacer con VFP en una sola línea, pero esos desarrollos desde mi punto de vista no tienen sentido alguno, por el alto coste que supone, salvo que hubiera algún tipo de exigencia en el guión :-)) de lo contrario es un problema de .... oopppp me abstengo para no decir burradas...
Si embargo es curioso que en VBA si existe tal concepto, por ejemplo esto en VBA sería correcto &NombreDeCampo y se realizaría la evaluación sin problemas, hasta el carácter es el mismo que usamos en VFP, se entiende que VBA no es comparable en ningún sentido con VFP, simplemente por comentar como el hermano pequeño de VB, es un poco más listo :-))))
En .NET la cosa cambia esto ya es otro cantar, pero no significa que sea tan sencillo como lo tenemos en VFP, y por supuesto debe de quedar claro y que no preste a confusión que en lenguajes de bajo nivel, no existe tal sencillez como en VFP, pero eso no excluye que se pueda hacer.
Esto lo pongo ya por la curiosidad del mismo y porque también los de VB lo suelen utilizar para ejecutar código script, pero no es comparable a la forma que podemos usar en VFP, donde el resultado de la forma es potencia y flexibilidad.
Por ello usamos el Script Control, esto sería soportado por cualquier lenguaje que soporte COM, ya sea VB, VFP o .NET.
Referencia a : MSScriptControl.ScriptControl
En VFP
loSC = CREATEOBJECT( "MSScriptControl.ScriptControl" )
loSC.Language = "VBScript" && Indicamos el lenguaje.
lcExpresion = "26 + 3 * 66"
lnResultado = loSC.Eval( lcExpresion )
?lnResultado
En VB tendría que ser algo como esto...
DIM loSC AS New MSScriptControl.ScriptControl
DIM lcExpresion AS String
DIM lnResultado AS Double
loSC.Language = "VBScript"
lcExpresion = "26 + 3 * 66"
lnResultado = loSC.Eval( lcExpresion )
ahhhh no me acuerdo como se pone en pantalla era un Print? da lo mismo oopppp...
También CScript soporta secuencias execute, muy interesante, pero ya no viene a cuento aquí.
En fin, y en una sola línea; en VB "macro sustitución" ja-ja-ja salvo que alguien lo hubieran soñado, por lo menos yo te doy toda la razón!!!
Pero, nunca podemos decir de forma absoluta que no se puede realizar, si VB lo tiene, pues NOppppp
Y en un supuesto lenguaje, que si estaría en la línea de comparación con VFP, esto deja mucho que desear por lo menos en este sentido. :-))
Saludos, Antonio Muñoz de Burgos
www.emans.com (Web realizada en vFoxPro)
Manifestando el apoyo a la comunidad de Visual FoxPro
"Fernando D. Bozzo" <***@ezrs.com> escribió en el mensaje news:%230d$***@TK2MSFTNGP12.phx.gbl...
Gracias Antonio por tus explicaciones que, como dijo Ana, son un lujo de detalles.
Respecto a la pregunta original de MEF sobre si esto se puede en VB, creo que la respuesta es que no, VB no tiene una equivalencia del comando & de VFP. ¿o me equivoco? :-)
Saludos,
Fernando D. Bozzo
"La programación es más eficiente cuando menos se piensa en el código"
---
"Antonio Muñoz de Burgos y Caravaca" <***@emans.com> escribió en el mensaje news:***@TK2MSFTNGP15.phx.gbl...
Hola Fernando:
No al contrario, espero no aburrir a más de uno, porque cuando empiezo a filosofar, hasta yo termino liado jajaja.
Entiendo, que son cosas que hay que interpretarlas cada una en su caso, desde mi punto de vista, no es sería correcto mezclar peras con melones, por eso justamente
Post by Fernando D. BozzoPost by Antonio Muñoz de Burgos y CaravacaEn fin, en cualquiera de los casos, no representa un problema
el poder ejecutar código generados online ;-) otra cuestión y
dependerá de varios factores, a la hora de poder decir la sencillez
de aplicación en un lenguaje u otro, entiendo que son lenguajes
que tienen distintos enfoques, como se suele decir, cada cosa
donde corresponde, al igual que a nadie se le ocurre realizar una
aplicación de gestión en ensamblador, bueno !!! no te extrañe que
exista por ahí alguno que este peor que nosotros ;-))
Aunque comentas que los ejemplos son rebuscados, eso no importa, no hay que ir tan lejos para ver la respuesta, te voy a poner un ejemplo mucho más sencillo y la respuesta se verá a simple vista, para que veas a lo que me refiero.
Donde es más fácil realizar; por ejemplo una apertura de una tabla en VFP o en C, la respuesta como se ve es obvia, en VFP (tenemos comandos nativos magníficos para este tipo de gestión)
Pero, si la pregunta es puedo realizar una apertura de tablas VFP en C, la respuesta sería se "Sí", utilizando los componentes correspondientes o no, sino de forma directa, pero eso no significa que no se pueda realizar.
Debemos tener en cuenta que la función y/o objetivo de C, no es tener un comando para abrir tablas, mientras que en VFP es obligado, además nos podemos dar cuenta que el comando USE de VFP para realizar la apertura de una tabla, no es más que código en C.
Y claro está en cual es más fácil hacerlo, pues en VFP porque ya lo tenemos resuelto.
Otro ejemplo fíjate en este código en C, de la función _DBSeek (esto lo puedes ver en la ayuda, ya que DBSeek esta a su vez en la foxtools),
_DBSeek nos sirve para buscar el registro cuya clave (de una tabla indexada) coincida con el valor val.
Código C
#include <pro_ext.h>
FAR Example(ParamBlk FAR *parm)
{
_DBSeek(&parm->p[0].val);
}
FoxInfo myFoxInfo[] = {
{"DBSEEK", (FPFI) Example, 1, "?"},
};
FoxTable _FoxTable = {
(FoxTable FAR *) 0, sizeof(myFoxInfo)/sizeof(FoxInfo), myFoxInfo
};
Si esto lo hacemos en VFP sería mucho más fácil, en una sola línea. ;-)
Pero confundamos el "se puede" con la "facilidad"
VFP esta eficientemente enfocado para realizar un tipo acción, con un entorno RAD para el objetivo que debe de cumplir, sin embargo lenguajes como C, tienen un enfoque y/o objetivo distinto, como por ejemplo poder crear una herramienta como VFP, un lenguaje que crea lenguaje por ejemplo.
En este tipo de casos, entiendo que existe una simple lógico para poder llegar a ciertas conclusiones de facilidad y/o dificultad, pero enfocándolo dentro de lo que corresponda.
Como ves mi respuesta es que en VFP es mucho más fácil, pero no porque sea mejor o peor como lenguaje sino que esta enfocado para un tipo de acción y tiene un objetivo.
Desde ese punto de vista, es al que me refiero que no debemos mezclar cosas, por eso ponía como ejemplo extrapolado que a nadie se le ocurre realizar un programa de gestión en ensamblador.
Si bien es cierto, nos hemos o me he centrado en VFP y C o C++, son lenguajes con objetivos muy distintos, por eso la comparación en tal aspecto no tiene mucho sentido, ahora si solamente nos basamos en dar un respuesta, de "se puede hacer", lo resumimos en dos letras "Sí".
Pero por ejemplo podemos realizar una comparación con Delphi, el cual tiene todos los atributos de un lenguaje con C y como VFP, es decir es de bajo nivel, pero a este lenguaje se le han acoplado y/o mejorado en todo aquello que hace referencia a un entorno RAD y gestión de datos, desde esta opción y sin entrar en su componente de bajo de nivel, incluyen todo o bastante en lo relacionado a la gestión de datos y muy eficientemente en el ejercicio de aplicaciones cliente/servidor en cuanto se refiere, y aplicar los ejemplos que has expuestos de una forma similar a VFP es totalmente posible ya que incluye comandos al igual que VFP para realizar dichas acciones.
Si me preguntas en cual es más fácil hacerlo, es algo que creo que nunca responderé de forma objetiva y no tendría mayor sentido, ya que muchas veces incluso dependerá de otros factores.
En conclusión y partiendo del origen de estos comentarios, lo único a lo que hago referencia es que el sistema se "evaluación" o "macro sustitución" no es algo exclusivo de VFP, ni mucho menos y la afirmación en cualquiera de los términos absoluta o no, es totalmente incorrecta.
Incluso podemos ir mucho más allá, ya que he trabajado con "macrosustitución" desde la época del MsDos mucho antes que existiera VFP, con lenguajes incluso como el ObjectPal que ya en aquellos tiempos hacia exactamente lo mismo, ni mucho menos, que a fecha de hoy lo realizan lenguajes como VFP y otros.
Post by Fernando D. BozzoPost by Antonio Muñoz de Burgos y CaravacaNo sé si fuí claro en el planteo, pero para intentar profundizar un poco más en lo anterior sólo
me cabe preguntarte si los ejemplos que te indiqué se pueden (o suelen) implementar
en C de forma más o menos sencilla.
Personalmente, no me ocurriría realizar una implementación como esa en C, para eso tengo VFP ;-) y en caso contrario si por algún motivo necesitará de un lenguaje de bajo nivel, y con implementaciones en dicho sentido como las de VFP, utilizaría Delphi, esto responde a lo que comentaba, se que estoy más para allá que para aca, pero vuelvo a extrapolar --> hacer un programa de gestión en ensamblador o más cerca aún en C, donde esta sentido de tal acción, creo que la respuesta responde a lo comentado en este mensaje.
Saludos, Antonio Muñoz de Burgos
www.emans.com (Web realizada en vFoxPro)
Manifestando el apoyo a la comunidad de Visual FoxPro
"Fernando D. Bozzo" <***@ezrs.com> escribió en el mensaje news:%***@TK2MSFTNGP12.phx.gbl...
Hola Antonio, realmente te agradezco todo el tiempo que te tomaste en escribir, me parece genial toda la explicación.
Ahora que entiendo adónde apuntás voy a especificar mejor a qué casos de macrosustitución me refería.
Hablaba de los siguientes casos:
Ejemplo 1:
lcSQL = "SELECT * FROM Tabla_A WHERE Campo_1 > 10 INTO CURSOR cMiCursor"
&lcSQL.
Ejemplo 2:
lcVariable = "VariableIndicadaPorElUsuario"
&lcVariable. = "UnValor"
Ejemplo 3:
lcTipoObjeto = "textbox"
lcDefObjeto = "CREATEOBJECT(" + lcTipoObjeto + ")"
loObjeto = &lcDefObjeto.
Ejemplo 4:
lcComando = "CualquierComando"
&lcComando.
Estos ejemplos, aunque un poco rebuscados, son un poco a lo que me refería. Intento destacar la naturaleza dinámica del código, donde hay asignación de variables cuyos nombres pueden llegar en parámetros, o sentencias SQL variables u objetos que se crean basados en un tipo que también puede estar parametrizado.
Me quedé pensando en lo que dijiste, de que VFP está hecho en C (que lo sabía) y que por lo tanto toda esta evaluación que hace VFP realmente está implementada en C, y creo que el punto que habría que separar acá es éste que voy a intentar explicar:
Cuando programás en C, usás instrucciones como void, main y todo eso. Si bién VFP está hecho en C, está preparado para interpretar los comandos que nosotros ponemos en los programas, como DO TalCosa, INDEX TalOtra o Select..., y todo el tema de la macrosustitución ya está elaborado. Pero cuando codificás directamente en C, no podés usar esto mismo porque cada uno de estos comandos son complejas implementaciones hechas en el mismo C.
A lo que voy es que trabajando en C creo que no tenés la posibilidad de hacer fácilmente lo que indiqué en los ejemplos, sin caer en la necesidad de reinventar la parte de VFP que se encarga de ello.
No sé si fuí claro en el planteo, pero para intentar profundizar un poco más en lo anterior sólo me cabe preguntarte si los ejemplos que te indiqué se pueden (o suelen) implementar en C de forma más o menos sencilla.
--
Saludos y gracias,
Fernando D. Bozzo
"La programación es más eficiente cuando menos se piensa en el código"
---
Post by Fernando D. BozzoPost by Antonio Muñoz de Burgos y Caravaca¿No es que el código fuente que escribís en esos lenguajes es "compilado"
justamente porque no se ejecuta en tiempo de ejecución, al contrario que en
VFP donde al ser "interpretado" en tiempo de ejecución permite generar nuevo
código sobre la marcha y ejecutarlo sin más?
No me queda claro lo de la comparación, ya que una cosa no excluye a la otra, intentaré explicarme:
En el caso de VFP es interpretado, es decir que cuando generamos el ejecutable, dicho fichero "no" es código maquina y necesita de las runtime para interpretar los comandos, a diferencia de los otros que realizan un compilado en código máquina, hasta aquí creo que hablamos de lo mismo.
Pero luego comentas, que permite generar nuevo código sobre la marcha, en cualquiera de los casos independientemente que sea interpretado o no, puedes generar código, dicho código en cualquiera de las formas esta en algún sitio, ya sea porque lo guardes en un fichero (del tipo que sea) o porque directamente está en el propio ejecutable, en cualquiera de los casos el ejecutable físicamente nunca crece, partiendo de esto, el que sea un ejecutable en código maquina o no, lo puedes hacer.
Ahora bien, entiendo que tú duda puede venir en lo siguiente, tú me corriges:
Que sucede en un ejecutable en código máquina, cuando en parte de ese código se deben de evaluar las variables que pueden contener código o no para luego ser explotadas como se quieran?
En un interpretado es más fácil de verlo, ya que como bien comentas entendemos que será procesado cuando se ejecute y se pueden evaluar las variables, cosa que sabemos que "no" sucede cuando usamos constantes en los "#DEFINE" este sería el lado opuesto.
Continuando en esta línea, pasemos a los no interpretados, para el caso es lo mismo, ya que para ello no usamos una variable de tipo normal (por identificarlo de alguna forma), sino que usamos punteros, para explotar el dato contenido.
Además debemos de recordar que cuando usamos en VFP una "macro sustitución" realmente esta siendo manipulado con código escrito en C++.
Para entender un poco más el caso, de forma coloquial definamos que es un puntero:
Podemos decir que un puntero no es más que un tipo de variable, que es usada para almacenar la dirección en memoria de otra variable, es decir no guardamos el dato convencional (esto es lo mismo que se aplica en "macrosustitución"), buscamos el contenido y no el nombre en sí de la variable, ya que eso es fácil de conocerlo (se entiende)
O sea, una variable del tipo puntero, nos permite acceder a esa otra variable, que se encuentra almacenada en la dirección de memoria que señala nuestro puntero.
Como podemos ver, el valor que tenemos en nuestra variable puntero, es una dirección de memoria, entonces, es cuando decimos que el puntero apunta a la variable almacenada en la dirección de memoria que contiene el puntero (vaya juego de palabras, pero es así)
Tengamos en cuenta o que no preste a confusión la variable apuntada no es el puntero.
Y aquí está lo que realmente queremos el "dato contenido" en esa variable apuntada, si te fijas lo que tenemos es el dato contenido, que es lo mismo que aplicamos en "macro sustitución" o con EVALUATE, el dato contenido en dicha variable, caso solucionado.
A efectos prácticos obtenemos lo que deseamos, en VFP se realiza de la misma forma, pero sin conocimiento por parte del desarrollador, parte de esto es justamente porque es un lenguaje de alto nivel y nos permite olvidarnos de procesos que pueden resultar costosos, para el desarrollo de aplicaciones al cual esta enfocada la herramienta.
Cualquier desarrollador, que utilice lenguajes de alto nivel, en nuestro caso VFP, obviamente; la conclusión será en VFP es muy sencillo hacerlo, eso es cierto, pero lo mismo en cualquier lenguaje de alto nivel que lo soporte, entendemos que justamente es eso lo que buscamos cuando utilizamos este tipo de lenguaje.
Sin embargo es digno de comentar que en el caso de Delphi, tenemos las dos opciones, la de bajo nivel y por supuesto comandos EVAL para evaluar las expresiones en el mismo sentido que lo hacemos en VFP, en el caso de Delphi, no es más que la evolución del Pascal, luego Turbo Pascal, por lo tanto es un lenguaje de bajo nivel, comparable totalmente a C++, pero con la diferencia que es un lenguaje fuertemente estructurado, pero el porque Delphi además de ser un lenguaje de bajo nivel, también es un lenguaje de alto nivel, simplemente porque se han añadido sin perder el origen del mismo opciones RAD.
Aunque esto poco viene a cuento, pero nunca esta de mas; una definición típica en TPascal de un puntero sería:
TYPE TipoPuntero = ^TipoVariableALaQueApuntamos
Un puntero puede apuntar a cualquier tipo de variable, y más aún incluso puede apuntar a un tipo estructurado (los tipos estructurados es algo que me gustaría tener en VFP) , en un tipo estructura podemos incluso colocar una estructura que puede ser la definición de columnas de una tabla para cargar un registro y poder tenerlo apuntado con un solo puntero.
Una variable puntero en si mismo es estática, ya que se crea al comenzar la ejecución del ejecutable (se entiende, donde este contenido), para nuestro caso no representa un problema como es lógico sabemos a quien se debe apuntar, pero además se puede apuntar a variables dinámicas, incluso para realizar optimizaciones en la memoria y utilizarlas cuando sea necesario.
Un caso muy representativo puede ser en un TreeView, para ir apuntando nodos, que son dinámicos en función de una serie de datos que pueden ser dinámicos.
Definición típica en TPascal (esto es de la epoca del MsDos) ufff nos vamos haciendo mayores, esto puede ser llevado a cualquier lenguaje que maneje punteros y estructuras, solo es cuestión de sintaxis:
Type MiPunteroNodo=^TipoESTNodo;
TipoESTNodo=Record
Dato:Integer;
Siguiente:MiPunteroNodo;
End;
Como se puede ver, podemos definir MiPunteroNodo=^TipoESTNodo, aunque no tengamos definido el TipoESTNodo.
En fin, en cualquiera de los casos, no representa un problema el poder ejecutar código generados online ;-) otra cuestión y dependerá de varios factores, a la hora de poder decir la sencillez de aplicación en un lenguaje u otro, entiendo que son lenguajes que tienen distintos enfoques, como se suele decir, cada cosa donde corresponde, al igual que a nadie se le ocurre realizar una aplicación de gestión en ensamblador, bueno !!! no te extrañe que exista por ahí alguno que este peor que nosotros ;-))
También es bueno recordar, que C, C++ son lenguajes ampliamente utilizados, para desarrollar Sistemas, incluso Linux esta desarrollado en C (no me preguntes en cual de las miles de versiones jajaja), y si no se pudieran hacer este tipo de operatorias, ni siquiera lo podríamos tener en lenguajes como VFP u otros, que esta desarrollados con los mismos ooppp ;- ) "evidentemente en estos casos se usa también ensamblador"
Saludos, Antonio Muñoz de Burgos
www.emans.com (Web realizada en vFoxPro)
Manifestando el apoyo a la comunidad de Visual FoxPro.
Post by Fernando D. BozzoHola Antonio, volví a leer tu mensaje, pero me queda una duda.
Sé que con punteros de memoria podés alterar el contenido del puntero o
incluso moverlo a otra ubicación, pero ¿pueden dichos lenguajes
(C++,Delphi,etc.) ejecutar código de programa dinámicamente generado?
¿No es que el código fuente que escribís en esos lenguajes es "compilado"
justamente porque no se ejecuta en tiempo de ejecución, al contrario que en
VFP donde al ser "interpretado" en tiempo de ejecución permite generar nuevo
código sobre la marcha y ejecutarlo sin más?
Gracias,
Fernando D. Bozzo
"La programación es más eficiente cuando menos se piensa en el código"
---