Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 12 Apr 2001
Offline Last Active Jul 13 2014 03:29 PM

Posts I've Made

In Topic: BSP Tree Question

13 July 2014 - 06:01 AM

Thank you for the detailed description :)

In Topic: OOP Design Question (C++)

11 January 2007 - 04:29 AM


okay, i´ll show you an example :)

my parser uses code like this:

consider this simple expression parser:

void parse_expr()
CVar* myLeftVal = /* irgs :( */ static_cast<CVar*>(_symTable.find_symbol(token.lexeme));

CVar* myRightVal = /* irgs :( */ static_cast<CVar*>(_symTable.find_symbol(token.lexeme));

create_mov_instr(myLeftVal.address, myRightVal.address);

Since the abstract symbol class has no address() member, i need to cast

i could provide an asbtract virtual function address() in the CSymbol base class, but this doesn´t make sense, then CType, which represents a data type also derives from CSymbol, has no address

Thanks, i give it a try ;) but is there a way to restrict the client to always use types of CSymbol?

In Topic: My Own scripting language - design?

09 January 2007 - 12:57 AM

Thanks for your answer, i want to go in a similar direction,
currently my syntax is fully C-oriented (with the same limitations (no OOP)), but performs very fast.

Another question i have is:

How do you code your virtual machine? To have process the instructions and memory access very fast, i thought it would be a better idea to use good old C to implement the VM. However, this makes the library more inflexible when it comes to adding new features / opcodes, etc.

What i want to prevent is a running loop like this:

for (each instr)
switch (instr.opcode)
case 0:
case 1:

or even worst, like this

virtual void Execute() = 0;

virtual void Execute() { ... }

derived classes for other instructions follow

for (i = each in instr)
i->Execute(); // Call i´s virtual Execute method

The third possibility, using Callbacks, is very fast:

typedef void (*INSTR_CALLBACK)(SCRIPT &script);

std::vector<INSTR_CALLBACK> _instrCallbacks;

for (i = each in instr)
_instrCallbacks[i->opcode](); // Call callback method

But it has following disadvantage:
I cannot directly access the memory, instruction, operand, etc

void mov_callback(SCRIPT &script)
INSTR currInstr = script.instr(script.curr_index));

script.mem.move(currInstr.operand[0].value.i, currInstr.operand[0].value.i);


Can someone give me a few ideas of which method is most suitable for best performance in script execution?


In Topic: Problem with push_back on vector

03 January 2007 - 08:31 AM

Original post by Palidine
no. you're storing that offset in the array thusly:

10 total bytes

allocate 1 byte
push_back a struct with a .size = 9

allocate 1 byte
push_back a struct with a .size = 8

allocate another byte
iterate the list

addr += 9
addr += 8

return _chunk + 17;

note that the addr offset is horribly wrong
note that _chunk + 17 is no where in your vector of memory because the pointer stored in _chunk has no relationship with the memory space of the vector


I´m just using the vector for holding information about the size of the block, they have no relationship to the memory addressed by _chunk, neither physically nor logically :)
the vector only keeps track of the number of blocks and the block sizes / as well as the status (used/unused)

The problem is fixed now, it was the error detected by Enigma. Now it works :)

In Topic: Problem with push_back on vector

03 January 2007 - 07:20 AM


Thanks for your help. But i think my code is a little bit confusing due to the fact, that the variable named "freeBlock" is somewhat misleading.

freeBlock is the "first fit" block that is greater than or equal to the bytes the user aquired, and freeblock is then marked as used, so it is no longer a freeblock but actual the block that is related to the allocated memory.

And then, newBlock is created to store information of the remaining free bytes

Lets say, i have a single free block of 100 byte,
and the user aks me for 80 bytes,
then i set this block´s size to 80 bytes, and create a new (free block) with 20 bytes in size.