Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


fastcall22

Member Since 04 Feb 2008
Offline Last Active Today, 07:27 PM

#5092822 Simple C++ Design Question for Numerology App

Posted by fastcall22 on 09 September 2013 - 03:57 PM

-Entire birth day condensed down to one digit.

-Date of birth condensed to one digit.

-Month and date of birth condensed to one digit.

...
What does this even mean?

Perhaps a few examples might clear things up...


#5090423 c++ polymorphisam deleting a object, constructor concearn

Posted by fastcall22 on 30 August 2013 - 01:12 PM

Here a leak of one int size will occur?

No.

If so, how would the base class know to call its pointing to deconstructor?

Make the base class destructor virtual.


In C++, it is considered good practice to use a virtual destructor:
class Base {
public:
    virtual ~Base() {
    }

private:
    bool mTest;
};

class Derived : public Base {
public:
    Derived() {
        mData = new int[1000];
    }

    ~Derived() {
        delete[] mData;
    }

private:
    int* mData;
    double mOtherData;
};

int main() {
    Base* p = new Derived;
    delete p;
}
If Base::~Base were not virtual, then Derived::~Derived would not be called, and the memory for its mData would not be released. The members for Derived (the pointer mData, mOtherData, and mTest) would not leak in either case, because the members reside inside the memory block allocated for Derived. Your C++ runtime and operating system keep track of allocated blocks, so the runtime/operating system is smart enough to know the size of a block given only the pointer to its address. You can technically do something like this:
void magic( void* ptr ) {
    // Neither ~Base() or ~Derived() will be called because we won't know what type ptr is!
    // But the memory block will be freed regardless.
    delete ptr;
}

int main() {
    magic( (void*)(new Derived) );
}
Whether it is morally acceptable to do or not is another question...


#5087722 Amusing glitch gallery

Posted by fastcall22 on 20 August 2013 - 08:23 PM

This is a cube.
obichamcube2.png

The camera was inside it. I learned about the importance of the near plane that day.
It got better though.

obichamcubecolor.png

Oops, range checking fail.


(Plug) Here are more screenies of its successor:
http://imageshack.us/a/img231/9179/fastbread.png
http://imageshack.us/a/img62/8483/torus.png



EDIT:
I don't remember imageshack being so hard to use...



#5085209 VSync messing with QPC() timing?

Posted by fastcall22 on 12 August 2013 - 09:41 AM

Are you saying VSync stalls the rendering function until the display has finished drawing the previously presented frame? So the "while(true)" only fires once every 16.(6) ms?

Yes, that is what Hodgman is saying; vsync blocks until the display is ready for another frame.

I thought it would make quite a mess of things, so I've decided to use a fixed step size.

Then you might find Fix Your Timestep an interesting read.


#5084233 Duplicated Code

Posted by fastcall22 on 08 August 2013 - 02:23 PM

The correct answer is to refactor four boolean variables into a single integer indicating which form is active:

private int currentForm = 0; // "firstForm" active
private int countForm = 4;
 
public void onKeyPressed( Event e ) {
    KeyEvent k = e.getkeyCode();
    if ( k == KeyEvent.VK_RIGHT )
        currentForm = (currentForm+1)%countForm; // Modulus wraps "fourthForm" to "firstForm"
    else if ( k == KeyEvent.VK_LEFT )
        currentForm = (currentForm+countForm-1)%countForm; // Adition and modulus wraps "firstForm to "fourthForm"
}



#5065559 VC++ 2010 preprocessor directives don't seem to be updating

Posted by fastcall22 on 28 May 2013 - 12:35 PM

You're being retarded. :P

Remember that each cpp file (translation unit) is compiled separately from the rest. Therefore, only EG_DEBUG_MODE will be defined for main.cpp. You'll need to define EG_DEBUG_MODE in each cpp file, or add it to your project's preprocessor settings.


#5062153 My ever-evolving coding style

Posted by fastcall22 on 15 May 2013 - 07:04 PM

I am a self taught hobbyist programmer. Today, my subconcious decided to be helpful and torture me with randomly fetched memories of my old coding style. Here's a sample of my coding style from when I was still in the C-with-classes phase, circa 2006:
class CFoobar
{
private:
	// Public member variables are bad, mmkay?
	int m_iFoo;
	RGB m_rgbBar;
	double m_dBaz;
	
public:
	// Encapsulation is good, mmkay?
	// I'm so clever, using a pointer to avoid both a get AND a set for each member variable!
        int *GetFoo() { return &m_iFoo; }
	RGB *GetBar() { return &m_rgbBar; }
	// (Repeat for every member of CFoobar)
};


void frobnicate()
{
	CFoobar *foo = new CFoobar();
	
	// Wow! This is much easer than writing foo->setFoo(foo->getFoo()+7);
	*foo->GetFoo() = *foo->GetFoo()+7;

	double thing = *foo->GetBaz();
	// etc...
	
	delete foo;
}
Yup. Complete with the Microsoft bastardization of the Hungarian notation and the ever-so-important C-prefix on the class names so you always when you're using a class and when you're using a struct.



Guuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu.


#5057956 3D draw colors bleed into 2D draw colors

Posted by fastcall22 on 29 April 2013 - 09:14 PM

A wild guess, but I see a glEnable/glDisable pair for every OpenGL state except GL_COLOR_MATERIAL. Perhaps your 2d triangles are inheriting your 3d object's green material color?


#5042811 reinterpret_cast problem

Posted by fastcall22 on 13 March 2013 - 01:47 PM

Still,the exercise asks: Why was not each element set to 1? I have no ideea how to explain it

Because you aren't setting each double to 1.0 -- you are setting each individual byte for the first double to 0x01. The layout for your double will be 0x0101010101010101, which is around 7.784e-304, according to IEEE-754.

You probably want to use std::fill instead:
double arr[4] = {};std::fill( arr, arr+4, 1. );

(Also, 1.0 looks like 0x3FF0000000000000 in memory.)


#5040100 Randomly Generating Lines...

Posted by fastcall22 on 06 March 2013 - 01:41 PM

I'm trying to randomly draw lines...
It produces 1 line :/

It's actually drawing the same line 10 times. This is because you are resetting the RNG after every iteration. See the System.Random constructor. The default constructor sets the seed to the current system time in seconds. Because it takes less than a second to draw those lines, you are getting the same seed, and consequently the same sequence of random numbers.

You'll need to move r before the loop.


#5035950 SFML Missile Speed

Posted by fastcall22 on 23 February 2013 - 07:09 PM

(The problem is partially solved for vertical directions only).

This is because you're only updating one of the two components; the Y component:

sprite.move(0,-missile->getVelY()*refreshRate);

You'll need to also include the X component:
sprite.move(missle->getVelX()*refreshRate, missle->getVelY()*refreshRate);

Of course, wouldn't it be easier to set the velocity when the rocket is created instead of having UpdateMissiles decide how they should behave?

To decide the velocity for a missile, it's a simple X=R*cos(angle), Y= R*sin(angle).

EDIT:


if(missile->getType() == Missile::Player){
    // Missile angle of player is only vertical
    sprite.move(0,-missile->getVelY()*refreshRate);
} else {
    // This part needs to change from vertical to angles of 45,90,135 degrees
    // sprite.move(0,missile->getVelY()*refreshRate);
}


This code is a bit of a code smell. If you want to have a variety of rocket behaviors, you may want to consider inheritance here.


#5031621 Initializing a variable

Posted by fastcall22 on 12 February 2013 - 05:53 PM

You need to add them after you get the input.

The code, int score4 = score1 + score2 + score3;, isn't read as "at any time, score4 is the sum of score1 and score2 and score3"; it is read as "store the sum of score1 and score2 and score3 into score4". Since score1 .. score3 haven't been assigned a value at the time, a compiler warning is issued. (On a side note, you'll need to divide by three to get the average.)


#5030278 Rand is the same every time.

Posted by fastcall22 on 08 February 2013 - 09:35 PM

Move line 16 after line 26.


#5030202 Quick Debug-Mode Question

Posted by fastcall22 on 08 February 2013 - 03:34 PM

If you're using Visual Studio, then go to the project properties and modify the preprocessor definitions field in the C/C++ folder. Be sure only the "Debug" configuration is set.

AFAIK, there's already a widely-accepted define "NDEBUG" that is set when optimizations are configured for the build (i.e., not-debug mode).


#5029863 Link Errors w/ SDL + XCode 4

Posted by fastcall22 on 07 February 2013 - 04:01 PM

Are you referring to this ctor?

No. I'm referring to your separation of Map in a header and source file. (Though, that constructor isn't quite right. std::vector::reserve allocates the memory for width*height Ts, but does not construct those Ts. On the other hand, using std::resize will create (default-construct) width*height Ts in map, which I assume is what you meant to do.)

Each cpp file is compiled independently of each other. When main.cpp is compiled, it knows of Map and its member function prototypes. When the compiler reaches Map<T>::Map(int,int) with T=int, the constructor definition isn't known to main.cpp for T=int, so the compiler continues on, leaving the definition up to the linker to resolve. Next, Map.cpp is compiled, it only includes Map.h, and doesn't export any classes, since it doesn't know what Ts to use for Map. Both source files compile successfully, and the linker steps in. main.cpp is looking for a Map<T>::Map(int,int) with T=int, and since Map.cpp didn't generate that specific constructor, an "undefined reference" error ("unresolved external symbol" in Visual Studio).

So, how do we get the a Map with T=int?
The FAQs I linked the in the previous post outlines several solution:

1. Keep the definition in the header:
// Foobar.h
#include <lots_of_dependencies>

template<class T>
class Foobar {
public:
    void frobnicate() {
        // ...
    }
};
Straight forward approach, though the definitions can clutter the header (style-issue/personal preference).


2. Move the definitions in a separate file (but include it in the header):
// Foobar.h

template<class T>
class Foobar {
    void frobnicate();
};

#include "Foobar.impl"

// Foobar.impl
#include <lots_of_dependencies>

template<class T>
void Foobar<T>::frobnicate() {
    // ...
}
Same as 1, though the definitions have been moved to another file. (Again, style-issue/personal preference.)


3. Separate the interface from the implementation, and export common types in a source file:
// Foobar.h
template<class T>
class Foobar {
    void frobnicate();
};

// Foobar.impl
#include <lots_of_dependencies>

template<class T>
void Foobar<T>::frobnicate() {
    // ...
}

// Foobar.cpp
#include "Foobar.h"
#include "Foobar.impl"

// Explicitly create Foobars for Ts in (int, double):
template class Foobar<int>;
template class Foobar<double>;
This approach keeps a strict separation between interface and implementation, and minimizes the dependencies Foobar requires on those that use it. This approach is a bit constricted, since the Foobar.cpp needs to be maintained for all Ts of Foobar that is used in the project. It does decouple lots_of_dependencies from those that include it, though.




PARTNERS