Page 1 of 2
developer input needed (re: new EQLib.cpp breakdown)
Posted: Tue May 20, 2003 10:44 pm
by Amadeus
I am finalizing the breakup of EQLib.cpp into more managable modules. My goal was to keep things logical and to retain the same header file for all files. During this breakdown I am changing no code other than adding some externs to EQLib.h for compilation purposes.
I've PMed DKAA and gotten approval for this breakdown; however, before I send it in I wanted to make sure that no one else had any other suggestions. As it is almost complete, I would ask that you stick within the basic concept of what I have proposed here if you make suggestions. My sanity thanks you.
Code: Select all
* [b]EQLib_Main.cpp[/b] - .dll insert, .ini file parser, etc.. (27 KB)
* [b]EQLib_Commands.cpp[/b] - All slash commands that are not macro related (94 KB)
* [b]EQLib_MacroParser.cpp[/b] - only the functions that deal with variables and macro parsing. (115 KB)
* [b]EQLib_MacroCommands.cpp[/b] - All slash commands that are usually used in macros (ie, /varset) (61 KB)
* [b]EQLib_Hooks.cpp[/b] - all hooks (11 KB)
* [b]EQLib_Interp.cpp[/b] - Only the functions that add slash commands to MQ (9 KB).
* [b]EQLib_MemChecks.cpp[/b] - all the memcheck routines (19 KB)
* [b]EQLib_Mouse.cpp[/b] - all mouse related functions (14 KB)
* [b]EQLib_TelnetServer.cpp[/b] - (11 KB)
* [b]EQLib_Utilities.cpp[/b] - All the utility functions (19 KB)
----------------
Note: I decided to make EQLib_Interp.cpp a seperate file so that individual users could have builds with custom slash commands in a 'EQLib_Custom.cpp' file without a lot of CVS interuption.
Posted: Wed May 21, 2003 1:01 am
by Clawed
Works for me, although this is only going to slow down my dev time with every new CVS release (to add in my functionality). Much easier to add new code into a single file. But I agree in concept that this is better.
Posted: Wed May 21, 2003 2:52 am
by dont_know_at_all
Learn the ways of diff and patch, young padawan.
Posted: Wed May 21, 2003 4:45 am
by Cheese
This is way better, and CVS will handle things a lot nicer too I'm sure.
Posted: Wed May 21, 2003 7:57 am
by Mckorr
Need to move all PERL functions out to their own file, and all Telnet functions as well.
Posted: Wed May 21, 2003 2:23 pm
by Amadeus
I was under the impression that the perl stuff was all mixed in with everything else. Certainly, I don't think I came across any functions that were specifically used ONLY for the perl implimentation. Maybe you could give a few examples if so.
Notice EQLib_TelnetServer.cpp ...has all the telnet server stuff in it.
Posted: Wed May 21, 2003 3:34 pm
by Mckorr
Yeah yeah, saw that after I hit submit and didn't feel like going back and editing.
Okay, how bout we just rip PERL out completely then. I still see no reason to have it in there... but then I see no reason for relative mouse movements either, and those are still in there.
Posted: Wed May 21, 2003 4:53 pm
by Amadeus
Once it's all divided up..someone else can remove it :)
Personally, I don't think it hurts anything, and you never know when some Perl guru might come along and make something useful out of it. My only beef with Perl is that the code looks ugly ..hehe
Posted: Wed May 21, 2003 6:41 pm
by Non M$ Coder
I used to be pretty good with perl, but I haven't really looked into how perl is used within MQ. btw, if you have embedded perl into the program, all that string manipulation mckorr is trying to do would be simplicity itself (if you know how to use embedded perl from within c, I got a book somewhere that talks about it, i only ever did very little the other way arround, embedding c within perl, and that was just to see if I could.) How does perl fit into the MQ picture? Oh, I think the book I have that talks about embedding perl is O'Reileys "Advanced Perl Programming".
Posted: Fri May 23, 2003 2:21 am
by Clawed
Learn the ways of diff and patch, young padawan.
Good smurfing point, and I'd like to point out that I work part-time as a moron for donations.
(I'll stop being so lazy and actually use some dev tools for once in my life, I guess.)
Posted: Fri May 23, 2003 2:42 am
by Jay
You know, I run a small software company (I mean small like 3 employees) and we have just been using standard "Hey, don't touch that file" method of control. This CVS system, all future projects will be cvs.
It is amazing. Of course we also did most developing as one HUGE cpp file and broke it down later... Still trying to stop people from doing that. You know how much it sucks to break 12000 lines of code from one cpp file to 4 or 5 .h and .cpp? Well I am sure one of you do
Jay
Posted: Fri May 23, 2003 9:50 am
by Mckorr
If you're company is developing code using Visual Studio use it's integrated revision control system instead of CVS. I believe MS calls it Source Safe. If you've got the tools, use them since they integrate with the whole development suite better. That way you won't have to exit the compiler, do a CVS update, then restart, etc.
Sourceforge uses CVS because it's a UNIX based system, meaning they have to integrate a whole host of different development environments. If they were catering strictly to Windows they would probably use Source Safe instead of CVS.
Posted: Fri May 23, 2003 2:49 pm
by kaz
nobody uses SourceSafe that I know, I've worked for many big development companies over the years, we always use CVS, some derivative of it or Perforce.
When I worked at microsoft in the site server/IIS team they didnt use SourceSafe either lol, they used a homegrown command line system that reminded me of CVS.
My company now has about 20 software engineers doing windows development, we use CVS. Speaking of that, probably the most usefull toolset ever on windows is cygwin.
I'm sure somebody DOES use SourceSafe, but from my experience CVS is a standard.
Posted: Fri May 23, 2003 3:34 pm
by dont_know_at_all
Even Microsoft doesn't use SourceSafe.
Perforce is better, if you have a large project.
Posted: Fri May 23, 2003 4:22 pm
by kaz
yeah I agree, Perforce is great for large projects since it operates with change *sets* rather than only changes to individual files like CVS does.
as an example for anyone who doesnt know what I mean, when you check in with CVS if you have 10 files modified as part of some change, CVS checks them all in 1 at a time, and if you need to rollback the change you'd have to rollback 10 commits.
With Perforce, the checkin is idenitfied as a set, and you can rollback the whole set.
For many small companies, small development teams though CVS is very adequate.