The max value for 64 bit is 7fffffffffffffff
Type: Posts; User: billboardplus
The max value for 64 bit is 7fffffffffffffff
Extremely disappointed in myself hahaha....That preprocessor function definition was not running where it was supposed to...
The original code was:
#ifdef JUICE_DEBUG
#define...
Well, I guess I have to start debugging the application in asm. I'll get back to you with an answer soon..
reserved::Allocated_Table_Locker.lock();
std::cout << data << std::endl;
std::map<void*, juice::string>::iterator it = reserved::Allocated_Table.find(data);
if (it !=...
Edit..problem not fixed. Did other tests and still having the same issues.
seekg() to the end, then tellg(), then seekg() to the beginning.
For particular data..
v1 = tellg(), then read..process, then v2 = tellg(). size = v2 - v1
I'm seeing a 448 bytes difference between both values. Compiled for x64
debug.h
#define juice_debug_removeallocated(a) juice::debug::RemoveAllocated(a)
namespace juice
{
namespace debug
{
JUICE_CORE_LIB void RemoveAllocated(void* data);
Found out std::vector<bool> packs data into 1 bit, preventing me from pointing a boolean to its data. The workaround is to use std::vector<char> instead of std::vector<bool>.
Fixed.
I just found out std::vector<int> returns int& for operator[]
std::vector<bool> returns std::_Vb_reference.
Weird...
Do I really have to use std::_Vb_reference?
inline void* GetArrayVariableFromType(void* data, size_t location, variabletype::e_type type)
{
switch (type)
{
case variabletype::_bool:
{
return...
Success! It worked! Thanks again to Dave11. Saved me weeks of work
Marked as Solution Found! Thanks to Dave11 and everybody else who tried to help.
A solution was found for that. Another dll gets generated containing all the required code for the destructor. That DLL stays in the program until the destructor for the variable is called.
It might sound weird, what I'm trying to achieve, but the user needs to modify the code because the Program uses that code to display certain data.
The problem is the user will modify its code, therefore, generating a new dll, and it needs to get reloaded. But Wait a minute! I think you found a solution! Thank you so much. Before the DLL gets...
Again, it's not a design issue. The DLL lets the program allocate a custom variable that will be used for something else. Forget the DLL, the variable needs to be used for something else. Meaning,...
Another solution would be to know the Size of the custom variable itself. Then, using delete to delete at the location of the variable + size of the variable, and it might call the Destructors? To be...
It's not a design issue, it's a must if I want users to be able to code their own modules using their custom classes or variables. while the program holds the variable itself.
The problem is Deleting Variables used by the DLL that the program does not know the type of. The variable can be anything you can imagine, even your own objects. It works only if the DLL does not...
Functions are stored in the program. The system use its own programming language. They are interpreted by C++. making it possible to copy functions between processes.
I forgot to mention, the variable needs to get deleted by the DLL function because since the program doesn't know the variable type, it can be anything, it won't call the destructors if it tries to...
The program needs to delete a variable while knowing its type, otherwise, it won't call the destructor.
The problem is, the variable must not get deleted when the DLL is detached. It's a variable created for the entire program.