Valhalla Legends Archive

Hi, this might be of some interest to you:
http://cs.stmarys.ca/~e_brooks/strtok.cpp
A robust splitting function, along the same lines as you have used.
You could improve on it by templating it to take std::basic_string< char > or std::basic_string< wchar_t >.

Quote from: Sorc.Polgara on October 15, 2005, 01:51 PM
Thanks for the responses!

Quote from: rabbit on October 14, 2005, 07:45 PM
Using printf() isn't a great idea.  You should throw an error instead, just in case the person using the DLL isn't writing a console based bot, or is using VB.

Is something like this better?  Is using cout not a good idea?

Code Select Expand


//==========================================================================
// Insert a DWORD into the packet buffer
void PacketBuffer::insertDWORD(DWORD insDWORD)
{
try{
if(chkBufSize(sizeof(DWORD)) == false){
throw "Cannot insert DWORD.";
}
}catch( char * str ){
cout << "Error: " << str << endl;
}

(-1)[(DWORD*)(buffer + (pos += 4))] = insDWORD;
}


Quote from: MyndFyre on October 15, 2005, 12:00 AM
The .insertStructure method could be templated as:

Code Select Expand


void PacketBuffer::insertStructure(LPVOID lpData, UINT uLength);


Would this work?

Code Select Expand


//==========================================================================
// Insert a structure into the packet buffer
void PacketBuffer::insertStructure(LPVOID lpData, UINT uLength)
{
try{
if(chkBufSize(uLength) == false){
throw "Cannot insert the structure.";
}
}catch( char * str ){
cout << "Error: " << str << endl;
}

(-1)[(LPVOID*)(buffer + (pos += uLength))] = lpData;
}


Quote from: Shout on October 15, 2005, 07:47 AM
You might want to look into using realloc() instead of malloc(), it resizes an allocated block of memory. I'm not sure, but I think excessive use of realloc() and malloc() may lead to fragmentation, so you might want to have the buffer resize itself in increments to avoid this.

Ok, so what your saying is that I should resize the buffer using realloc() every time I add something to the buffer using just the needed space.  For example when adding a DWORD to the buffer, resize the buffer so that it reallocates it 4 more bytes?

------
I'm so fucking newb.  What I know about C++ is basically the stuff from the very limited and basic High School level C++ course and what I've learned on my own.  I'm really regretting having made a bot in VB because it has made me ignorant.  C++ is so much more powerful, and because of that it is way more complicated.  It requires you to work more carefully with memory and stuff.  Plus there are so many little things that can make your code better that I wasn't taught.  The little tidbits.

EDIT:  Wow, do some of you guys program for a living?

If you need room for one more "DWORD", don't just allocate current size + sizeof DWORD, allocate twice the current size of the buffer. 1.5 times the current size of the buffer is good too. 1.5 is the strategy std::vector uses for growth. Also, why throw an exception? Either resize the buffer transparently, or return some error code.

Quote from: Sorc.Polgara on October 13, 2005, 11:40 PM

Quote from: Eibro on October 13, 2005, 11:13 PM
Just from looking at your interface:
Don't have "make BNCS packet" and "make BNLS packet" member functions. This severly limits the codes reuse. Trade "insertFILETIME" for some sort of generic, templated "insertSTRUCTURE" function. Then you could do buf.insertStruct<FILETIME>( p ). Likewise, for my first suggestion, instead of writing buf.insertBNLSHeader( 0 ) write createBNLSBuffer( buf )

Hmmm if I were to do this createBNLSBuffer( buf ) instead of this buf.insertBNLSHeader( 0 ), I would need to pass it a buffer...  errr, shit, I have to think of a way to say what I'm trying to say...

Ok, so like for a example of code if I were to make the change would be something like this?

Code Select Expand


PacketBuffer pBuffer;
LPSTR tempBuf, buffer;

pBuffer.insertDWORD(0x0C);
pBuffer.insertWORD(0x15);
pBuffer.insertNTString("I'm newb");
tempBuf = pBuffer.dumpBuf();
buffer = pBuffer.createBNLSBuffer(tempBuf);


Just trying to figure out what you are saying to do...


You see, I have this member function named dumpBuf() that can be used instead of either bnlsBuffer() or insertBNLSHeader()... that way you're not forced to have to choose between making the packet a BNLS or BNCS format... You can simply make the packet with no packet head at all.  The insertBNLSHeader() and insertBNCSHeader() member functions are like optional I guess you could say.

I'm willing to try your suggestion, I just don't know exactly what you mean.


Also, you suggested making a more generic structure function instead of the insertFILETIME() function.  I vaguely remember reading about making Templates... it has been awhile since Junior year of HS.  I'll have to look it up.  Good thing I still have all my C++ books.

If they are "optional" they really shouldn't be part of the class interface then. Strive for an interface that is minimal and complete.

Of course you're going to need an additional buffer object if you move to the interface changes I suggested. You would write:

buf = createBnlsPacket( packetBuffer, 0 );

Where buf was usually something like auto_ptr< WSABufEx >, and WSABufEx was basically:
struct WSABufEx : public WSABUF {
    virtual ~WSABufEx() { delete[] data; }
    u_long pos;
};

Just from looking at your interface:
Don't have "make BNCS packet" and "make BNLS packet" member functions. This severly limits the codes reuse. Trade "insertFILETIME" for some sort of generic, templated "insertSTRUCTURE" function. Then you could do buf.insertStruct<FILETIME>( p ). Likewise, for my first suggestion, instead of writing buf.bnlsBuffer( 0 ) write createBNLSBuffer( buf )

Quote from: hismajesty[yL] on October 10, 2005, 06:35 AM

Quote from: Lenny on October 09, 2005, 10:45 PM
2240 SATs?

No one going for a reach college?
Surprised I haven't heard anyone say MIT, Berkely, Stanford, Cornell, Carnegie Mellon, or those other top engineering schools...

Graduate school will be Ivy, I hope. My cousin went to Cornell but dropped out. I'd like to go there, Harvard, or maybe Yale for law school.

Didn't you just say you were a junior in highschool? And you're already considering graduate school? I think you will be very suprised how things will change in the next few years.

boost::any?

Quote from: hismajesty[yL] on July 22, 2005, 08:56 AM
I considered doing online poker, but Paypal added online gambling to the list of things you can't use their service for.

Blah, using paypal would involve all their transaction overhead anyway. Doing a wire transfer from your own bank account is the easiest option if your parents won't help you out.

Quote from: Arta[vL] on July 18, 2005, 09:26 PM
Because, imho, a well-designed OO program is more maintainable, more extensible, and more reusable than its procedural counterpart. Note that I said well-designed - which is hard. I think this applies to all but the most trivial of programs.

Also, since is C++ a superset of C, it will let you do everything as you would otherwise have done it in C, but with the added benefit of better type safety and other useful language features. It's not just classes.

Since C++ is 'C' '++', you may as well use it, just in case you want the '++' later

It seems like your views on this subject have changed since I last lurked. I always pegged you as a n advocate of procedural programming.

Two summers ago I made $6.39 working at an office supply store. One summer ago I made $8.50 working in construction. This summer I make $19.00 as a programmer, plus $15.00 (or whatever I choose) an hour tutoring. Funny thing is, I couldn't land a regular job prior to this summer aside from those brief stints of summer employment. My standards have always been high-- I wouldn't work for minimum wage. Now I don't think I would work for anything less than $10/hr.

What do I suggest doing? Start playing online poker. Pick up a good book on the subject and learn as much as you can. Invest all your money into it. Play the small tables until you can win, then move on up. Don't be afraid to lose everything and borrow from friends. It's very addicting (and profitable).
(But seriously, you don't have to be that great of a player to start seeing a profit. Plus it's non-taxable income, and you can work from your home!)

If you were to dig deeper into the language features, I don't think you would be having these problems. Ever hear of Resource Acquisition Is Initialization, or the Scoped Lock idiom?

Wouldn't it be cool if you could do this (or something similar)?

typedef basic_auto_handle< HANDLE, CloseHandle > auto_handle;

void fn() {

   auto_handle h = CreateFile( ... );
   auto_handle h2 = CreateFileMapping( ... );
}

Now the destructors of h and h2 will clean anything up that needs to be cleaned. Even in the face of exceptions, resources will still be freed. I don't agree with what you cited: http://www.joelonsoftware.com/items/2003/10/13.html. If you're writing exception safe code from the start, it doesn't matter how many possible "invisible" exit points there are. See Herb Sutter's Exceptional C++, and More Exceptional C++ for some in depth examples of writing exception safe code.

No, i'm talking about delay loaded DLL's with implicit linkage. e.g. winsock.dll won't be loaded until the program calls code provided by the DLL, then the loader will kick in and load the DLL. I haven't had time to look into it, but there's probably thunk in the IAT for all delay loaded imports that kickstarts the loader when it gets called to.

Does anyone know how I can detect the load of a delay loaded DLL from my application? I want to put some hooks on a delay loaded dll but I can't do that unless I either a) inject the code after the dll is loaded, or b) detect when its loaded and apply the hooks accordingly.


Thanks.

Quote from: tA-Kane on February 08, 2005, 09:57 AM
Thx for the heads up people. Now I have to fix more. 

As for checking if the pointer is NULL before attempting to free, I'd rather do that locally and be assured that delete isn't going to get screwy with me.

Quote from: EpicOfTimeWasted on February 07, 2005, 07:35 PMin your case, new will never return zero, it will throw bad_alloc.

When will it return zero?

It won't. It's guaranteed to do nothing with a NULL pointer.

Another thing is that delete and delete[] will take no action on a null pointer, so if ( saved ) delete[] saved; is not necessary.

Quote from: UserLoser on January 18, 2005, 05:03 PM

Quote from: Adron on January 13, 2005, 09:19 AM
They're all stupid trends?

Sie werden sich hinsetzen. Sie werden ruhig sein. Sie werden nicht beleidigen Eibro.