Jump to content

  • Log In with Google      Sign In   
  • Create Account


TheComet

Member Since 02 Oct 2013
Offline Last Active Today, 10:39 AM
-----

#5147689 dllexport global variable

Posted by TheComet on 17 April 2014 - 11:11 AM

Usually you'll want to define a macro for doing this:

#ifdef COMPILING_DLL
#   define API __declspec(dllexport)
#else
#   define API __declspec(dllimport)
#endif

// NOTE: Might want to throw the above into an "export.h" file

extern "C" {
    API DWORD NvOptimusEnablement = 0x00000001;
}

Though you're probably better of defining it in the .cpp file as:

DWORD NvOptimusEnablement = 0x00000001;

And in your header file use:

extern "C" {
    API extern DWORD NvOptimusEnablement;
}

That way you're guaranteed that it will only be exported once.




#5147625 Writing model 3D Model data to a new file as a new format

Posted by TheComet on 17 April 2014 - 07:32 AM

You might also want to consider using a library to save you from writing your own exporter/importer.




#5147377 c++ oo syntax behind the scenes behavior

Posted by TheComet on 16 April 2014 - 10:06 AM

When you define/instantiate an instance of a class using the new operator, sizeof(ClassName) number of bytes are allocated on the heap, and a pointer pointing to the beginning of the instance is returned.

ClassName* instance = new ClassName(); // memory is allocated on the heap here
instance->doSomething();

When you define/instantiate an instance of a class on the stack, the memory is guaranteed to be allocated when you need it.

ClassName instance; // Memory is allocated on the stack here
instance.doSomething();

The VMT is typically stored by adding an extra private pointer member variable to the class, which points to a virtual table. Every instance of the class generally shares the same virtual table.

 

If you add more virtual functions, the class size does not grow though.

 

This can be shown with the following code:

#include <iostream>

class Foo
{
public:
    Foo() {}
    virtual ~Foo() {}
private:
    int a;
};

class Bar
{
public:
    Bar() {}
    virtual ~Bar() {}
    virtual void set( int a ) { this->a = a; }
    virtual int get( int a ) { return a; }
private:
    int a;
};

int main()
{
    std::cout << "sizeof(Foo): " << sizeof(Foo) << std::endl;
    std::cout << "sizeof(Bar): " << sizeof(Bar) << std::endl;

    return 0;
}

 

Foo and Bar have the same size, even though Bar has more virtual functions.




#5146301 Static as substitute of private members.

Posted by TheComet on 11 April 2014 - 09:30 AM


What do you mean "implicitly static"? If you have two compilation units that define variables with the same name in the global scope and none of them are static, you will get a "multiple definition" error when linking. There is no such thing as "implicitly static".

I was mistaken, sorry.




#5146281 Static as substitute of private members.

Posted by TheComet on 11 April 2014 - 08:52 AM

[never mind]




#5146248 Static as substitute of private members.

Posted by TheComet on 11 April 2014 - 07:38 AM

 

 


Static is not a replacement for private in C. Declaring and defining them only in the .C file is.

 

Don't they need to be declared static inside the .C file so that they only visible from within that compilation unit.

 

 

No, each compilation unit is compiled individually, a variable has to be declared as extern to become accessible across compilation units.

 

 

To expand on what people are saying with a few examples:

 

 

 

CASE 1

 

test.h

extern int x;
void foo(void);

test.c

int x;
void foo(void) { x = 1; }

main.c

#include "test.h"
int main(void)
{
    foo(); /* ok */
    x = 6; /* ok */
    return 0;
}

x and foo() are both visible in external modules.

 

 

CASE 2

 

test.h

/* extern int x removed */
void foo(void);

test.c

int x;
void foo(void) { x = 1; }

main.c

#include "test.h"
int main(void)
{
    foo(); /* ok */
    x = 6; /* ERROR, x undeclared */
    return 0;
}

x wasn't declared as extern in the header file and is therefore invisible to external modules.

 

 

CASE 3

 

test.h

extern int x;
static void foo(void);

test.c

int x;
static void foo(void) { x = 1; }

main.c

#include "test.h"
int main(void)
{
    foo(); /* ERROR: foo() undeclared */
    x = 6; /* ok */
    return 0;
}

foo() was declared static and therefore is invisible to external modules.




#5145479 What it's like to be a software engineer (video)

Posted by TheComet on 08 April 2014 - 03:00 PM

It's interesting, because the issue here is not it being impossible, the issue here is communication.

 

What the engineer is doing wrong is he's saying things like "it won't work because <reason>", instead of trying to wrap his head around what the customer really wants by saying something like "Splendid idea, I am capable of implementing it. Could you demonstrate to me how you expect the end result to look like?".

 

The customer obviously doesn't exactly know the implications of her request down to the last detail. The customer and the engineer speak two entirely different languages, and it is the engineer's job to translate the customer's language into their own language without rejecting the customer's ideas.




#5144988 Problem with vignette shader on PC

Posted by TheComet on 07 April 2014 - 05:17 AM

Good job on finding the core of the issue. I hope all goes well!




#5144697 Amusing glitch gallery

Posted by TheComet on 06 April 2014 - 05:43 AM

Stumbled across this one on tumblr. How on earth does something like this even happen?!

 

https://www.youtube.com/watch?v=9pQ_ZozZIio




#5144319 Problem with vignette shader on PC

Posted by TheComet on 04 April 2014 - 06:03 AM

Maybe try using gl_TexCoord[0].xy instead of gl_FragCoord.xy. I remember having a similar issue where gl_FragCoord would return the correct value in GLES, but in GL it would always be 0.




#5142254 Javascript Memory leak

Posted by TheComet on 26 March 2014 - 03:44 AM

For the record, the correct term is "sawtooth" and not "zig zag pattern"

(sorry for being a jackass)




#5141993 Program Stopped Working (MinGW)

Posted by TheComet on 25 March 2014 - 08:25 AM

There is a multitude of possible problems but I would probably start with ensuring all runtime dependencies of the program (starting with the C++ runtime) are available when using the command line.

Yes, this was indeed the issue. libstdc++-6 was trying to be loaded, but was not in the path of the executable.

 

Thanks! I knew it was something simple.




#5141732 Best way of volume selection

Posted by TheComet on 24 March 2014 - 10:59 AM

The game Cosmo Bots demonstrated a 2D version of what you're after. It could accurately figure out your intentions through a combination of mouse movement and ray-tracing (I think it would prefer to rotate towards the nearest wall). If you weren't happy with its orientation, you could right-click the mouse to manually rotate it.

 

I think the most intuitive method would be to rotate the volume on the 2D surface of the currently selected block, according to an average mouse direction. This would be done as follows:

  1. Determine the surface normal the mouse cursor is over. For instance, if the mouse is on the top side of a block, the normal would be [0,1,0], where as if the mouse were on the side of a block, the normal would be [1,0,0] etc.
  2. Calculate a normalised directional mouse movement vector in 3D. This could be done by storing, say, the last 30 3D mouse positions in a ring buffer, and calculating the difference between the first and last point.
  3. The normal from step 1) is the axis around which you should rotate the volume selection. Using the mouse direction, you are able to calculate an optimal angle for the volume selection. You'd of course round the angle to 90° steps.
  4. Make sure the volume doesn't intersect with any other blocks, adjust position and angle accordingly.

Does that make any sense? I can create some illustrative images with MineCraft if not...




#5139309 Help name a game.

Posted by TheComet on 15 March 2014 - 02:50 PM

  • Unstoppable Shark Slaughter
  • Vegetarian Pirate Gladiator
  • A Pirate's Bible Cover up
  • Super Sexy Pirate
  • Jack Sparrow's Tricycle Crash
  • In search of Davy Jones' Vibrator
  • Hillbilly Pirate Force of Doom
  • Pirate Plays Enraged Chess
  • Flamboyant Voyage of The Sunken Quantum Summoner
  • The Ship From Outer Space
  • Fabulous Pirates Enrage Gay Activists
  • Black Beard Was Actually Black
  • The Penguin Conflict
  • Haunted Walrus in Funkytown
  • No One Can Stop The Yak Domination



#5139257 Need help: a vector of different extended classes

Posted by TheComet on 15 March 2014 - 10:45 AM

No, because that way, arrow will be destroyed as soon as it goes out of scope, and your list of entities will be holding an invalid pointer pointing somewhere above the stack. You have to use new and delete.
[EDIT] As SiCrane points out below, delete the element before removing it from the list.
// adding entities
Entity* arrow = new EntityArrow();
entities.push_back(arrow);

// removing entities
delete *it; // make sure to delete the entity being removed from the list
entities.erase(it);
Better yet, use smart pointers, so you don't have to manually delete the entities you remove from the list:
 
std::vector< std::shared_ptr<Entity> > entities;

// adding entities
std::shared_ptr<Entity> arrow = new EntityArrow();
entities.push_back(arrow);

// removing entities
entities.erase(it);
// entity is automatically deleted when you remove it





PARTNERS