Mail Archives: djgpp/1999/04/29/14:01:15
Thiago F.G. Albuquerque wrote:
> > I was forced to use VB5 at work. I don't like BASIC, but the
> interface is
> >very nice. It uses a similar interface to VC++6. If you type the name of
> a class
> >object and a '.' (as well as "->" in C++) and it lists all of the public
> members
> >of the class. Also, if you type the name of a function it doesn't
> actually type
> >out the prototype, but prints the syntax just below the cursor in a small
> "Tool
> >tip" style window.
>
> You know, when the are compiler errors, and you press enter over an error
> message in MessageWindow... then the cursor goes to the line the error
> refered to. The line it highlighted and... the error message is displayed
> in the bottom line of the editor window! (That's where I wanted to get to)
> Since RHIDE doesn't have "ToolTips", we could use that line to display the
> prototype.
That is exactly what I've almost finished. I'm having a little trouble
getting SetEdit to display the output of an external program in the messages
window, but I've got most of that done.
> >in it (these were the libc entries starting with "po"). You could then
> select one
> >and press enter, and it would finish the function name, then show the
> syntax. It
> >may be silly to use this for 3-5 character function names, but it would be
> very
> >nice for weird classes with long member names. But it would have to
> actually scan
> >the code for prototype definitions (so it could get the local
> functions/classes).
>
> I don't think scaning the code is a good idea. It is too complex, and
> probably too slow. (Have you ever used VC++'s WizardBar?) The only example
> of fast code scanning I've ever seen is RHIDE's "Goto to Function". I don't
> know how SET implemented that, but the result is just perfect. The docs
> mention some "heuristic"... VC++ probably uses some brute force algorithm,
> I guess; that's why it is too slow.
What I tried doing on my machine is sending the file through the
preprocessor, then through sed (to de-tab the file, because there are tabs in
stdio.h which screw up my searches), then through grep. It is not slow on my
machine, in fact, it is virtually instantaneous.
> My idea was RHIDE to keep a list of header files in which to search for the
> matching prototypes. For instance, my list would have all the libc headers
> (or I could merge them in one file) and allegro.h. Then if you wanted your
> own functions to "join the game", you could add your headers to the list.
>
> It's just like running grep on the list of header files.
That is almost exactly what I am doing, only I don't think having an
external list of functions would be a good idea. First of all, it is just
another thing that needs updating when the code gets changed. Second of all,
it requires for you to edit some file every time you make a new function.
> I don't see what does it have to do with preprocessing. You're just
> inserting text into your code. The next time you compile, the compiler
> deals with it.
If you don't do preprocessing, then you limit the functions you can find:
#define func(ret, name, code) ret name() {code}
func(int,function,return 578)
OR
int /* return value */
printf /* function name */
( char*, /* format string */
... ) /* the rest */
Preprocessing gets rid of all of the comments and expands all of the macros
in case some of the functions use macros in their definitions. It also gets
rid of conditional compilation blocks:
#ifdef ...
...
#endif
But MOST IMPORTANTLY, it does all of the #include expansion. I would hate
to do that myself, I'd have to parse all of the code, then find out what
directories are set up for include file searching, then I'd have to look in
those files ....
I think it is a lot easier to use what someone else already made.
--
(\/) Endlisnis (\/)
s257m AT unb DOT ca
Endlisnis AT BrunNet DOT Net
Endlisnis AT HotMail DOT com
ICQ: 32959047
- Raw text -