Re: LCCWIN ver WATCOM, BORLAND and interpreter
- Posted by euman at bellsouth.net Oct 20, 2001
- 409 views
> Hi Euman, > from the point of view of a compiler, it is not actually a bug. This is > because a compiler doesn't know what the variables and function mean. It > doesn't know what your intentions are. This would imply that LCC is rather intuitive when it comes to the windows API. This too could explain why LCC compiled programs are generally 1/3 the size of a Borland compile program. My being careless/reckless with the use of descripts has to be retaught. In the program the example I posted came from, I was supposed to have iChild allocated and the return from the sendMessage = hChild so it really is like finding a needle in a hay stack when one letter has got you. > > For example, even if the compiler did know that "allocate_string2" takes > some memory from the system and allows your program exclusive access to it > and that this would normally be returned at some point by your code, the > compiler doesn't know that you intend to return that specific bit of memory > to the system. Just because you use a free() function later on, doesn't > absolutely make it necessary that you were intending to return the memory. > It might be required for any number of reasons and could be kept until the > program ends. Also, there is no way that the compiler would know that a call > to SendMessage using those specific parameters does not return some > allocated memory that you just happened not to need (thus you free()'ed it > immediately). > > Because Euphoria has a simple 'type' system, it makes it hard for any > compiler (or Euphoria itself) to know what you were intending. > > In 'C' one might have declared iChild as ... > > char *iChild; > > and the declaration for allocate_string2 would most likely have been > something like ... > > char *allocate_string2(char *s); > > thus when you use it in your code, the data type declarations match and the > compiler can guess tat you know what you are doing. If the sendMessage() had > been declared as ... > > unsigned long sendMessage( ... ); > > then by assign its return value to iChild would have told the compiler that > you were attempting to assign an unsigned long value to something that is > supposed to hold a pointer to a character. Thus a data type mismatch could > have been detected and reported on. > > Its a tough call for the Euphoria translator to guess the correct data type > that you intend for the Euphoria variables. Maybe this is the area that > needs more thought etc... > Thanks Derek, > --- > Derek