Posts by mike_2000_17

Statically linking the libraries into the executable is not a problem at all. However, you have to be careful about a few things.

First of all, if you have an external library that provides a DLL and an import library (.lib on Microsoft compilers, and .a on others) then you cannot use that library for statically linking to it. The "import library" is essentially a static library which acts as a thin layer of functions that perform the dynamic linking of the DLL file (when the executable starts), it basically loads / unloads the DLL and attaches the function pointers of the DLL to the functions in the executable. You cannot use that library to statically link the entire code of the DLL into your executable.

So, you first need to make sure that you have the static library that contains all the code of the DLL, i.e., a static version of the dynamic library. This static library must have been compiled from the source code of that external library, it cannot be obtained from the DLL. So, if that is not what you have, you must get it, if you can't get it, then tough luck, you have to use the DLL (and distribute it with your application).

Second, if the external library in question also has external dependencies of its own (could be system DLLs or other external library DLLs), then to perform the static linking to that external library, you also need to link to all its …

You would probably be better off using an off-the-shelf library for that, like the Open Dynamics Engine (ODE). It's a simple but pretty solid engine for doing computer game physics realism (not for real simulations, of course). The basic idea with this is that you control your objects (characters, vehicles, projectiles, etc.) by specifying initial velocities and applying force to them (e.g., steering, thrust, etc.). Then, the physics engine takes care of the rest (realizing the motion). ODE has simple collision detection routines too, like primitive to primitive collisions (box-box, box-sphere, etc.). I don't think that it does 2D physics though, if that is what you need.

For doing "frame independent movement", it usually involves at least two threads of execution, one for rendering and one for physics simulations (or motion time-integration). The physics simulation is there to update the position (and orientation) of your models with time. The basis for this is ordinary differential equations (ODE) and numerical integration. First, given a system of rigid bodies (e.g., solid objects), there are laws of classical mechanics that help you to compute the acceleration (and angular acceleration) of a body given its state (position, orientation, velocity and angular velocity) and external forces applied to it (gravity, friction, thrusts, etc.), these are called the governing equations (and in rigid-body dynamics, the easiest form is the Newton-Euler Equations), and they are ordinary differential equations (usually). Collisions come in as a large impact force as two …

So much confusion, you seem to have confused yourself too. Cracker and Black Hat Hacker are not synonymous at all.

The term Hacker (black or white or whatever) refers to someone with the technical skills and ingenuity required to deconstruct systems in order to find weaknesses in them which can be exploited for purposes other than those they were intented for (or normally permit). For hackers, their interests lie in developing the means, not so much the ends.

The term Cracker refers to someone who merely uses tools, codes or methods created by hackers to carry out their mischievous (or political) activities. Crackers are solely interested in their ends (goal), good or bad.

As for alternative names:

For cracker, I like the term lacker, as a combination of "lacking skills" and "wanna be hacker". That is especially appropriate if the person in question brags about being a hacker, then you can tell him, no, you're a lacker.

As for crackers that purely do mischievous acts (hijacking emails, stealing credit card numbers or other info, bricking computers, etc.), what's wrong with just calling them fuckers, assholes, mother fuckers or bastards, or any other term that daniweb's language filter will block.

As for hackers, I never understood the whole "black hat" or "white hat" thing, what's wrong with "good" and "bad", it's much shorter and to the point. Why not call them "good hackers" and "bad hackers"? And, as far as I know, "bad hackers" (not crackers) are so rare that you …

In C++, you need to do the cast explicitly:

static unsigned char row[4];
static unsigned short *p1 = reinterpret_cast<unsigned short *>(&row[0]);
static unsigned short *p2 = reinterpret_cast<unsigned short *>(&row[2]);
static unsigned long *long_random = reinterpret_cast<unsigned long *>(&row[0]);

That should solve your problem.

I don't think that Dani submitted anything, at least, not that I could see when reviewing. So, she can't win.

You can make a very simple serializer like this: (warning: this is neither robust nor usable as is, at least, not to my standards)

#include <fstream>

class iserializer {
  private:
    std::ifstream in_file;
  public:

    iserializer(const std::string& aFileName) : in_file(aFileName.c_str(), std::ios_base::binary) { };

    template <typename T>
    friend
    iserializer& operator >>(iserializer& in_serial, T& value) {
      in_serial.in_file.read((char*)&value, sizeof(T));
      return in_serial;
    };
};

template <typename T, typename Allocator>
iserializer& operator >>(iserializer& in_serial, std::vector<T,Allocator>& value) {
  typedef typename std::vector<T,Allocator>::size_type SizeType;
  SizeType sz;
  in_serial >> sz;
  value.reserve(sz);
  for(SizeType i = 0; i < sz; ++i) {
    T tmp = T();
    in_serial >> tmp;
    value.push_back(tmp);
  };
  return in_serial;
};

template <typename T, typename Allocator>
iserializer& operator >>(iserializer& in_serial, std::list<T,Allocator>& value) {
  typedef typename std::list<T,Allocator>::size_type SizeType;
  SizeType sz;
  in_serial >> sz;
  for(SizeType i = 0; i < sz; ++i) {
    T tmp = T();
    in_serial >> tmp;
    value.push_back(tmp);
  };
  return in_serial;
};

class oserializer {
  private:
    std::ofstream out_file;
  public:

    oserializer(const std::string& aFileName) : out_file(aFileName.c_str(), std::ios_base::binary) { };

    template <typename T>
    friend
    oserializer& operator <<(oserializer& out_serial, const T& value) {
      out_serial.out_file.write((const char*)&value, sizeof(T));
      return out_serial;
    };
};

template <typename T, typename Allocator>
oserializer& operator <<(oserializer& out_serial, const std::vector<T,Allocator>& value) {
  typedef typename std::vector<T,Allocator>::const_iterator Iter;
  out_serial << value.size();
  for(Iter it = value.begin(); it != value.end(); ++it)
    out_serial << (*it);
  return out_serial;
};

template <typename T, typename Allocator>
oserializer& operator <<(oserializer& out_serial, const std::list<T,Allocator>& value) {
  typedef typename std::list<T,Allocator>::const_iterator Iter;
  out_serial << value.size();
  for(Iter it = value.begin(); it != value.end(); ++it)
    out_serial << (*it);
  return out_serial;
};

Then, your custom …

I just cast my votes. And, of course, I didn't vote for my own snippet, even though it is clearly the best ;) (shameless plug)

I don't think the analogy with an election makes any sense. In an election, you choose the person or party that you would most like to see in charge of things, because of what you think/hope they will do once in office, or because he/she/they represent your positions / opinions / world-view. In case of elections, clearly, you should vote for yourself if you're a candidate. However, in this kind of a contest, the idea is to try to judge the work that has been done using your expertise and objective appreciation for its merits. Voting for yourself (at least, if you are voting just to give you a better chance of winning) is not OK in my opinion because it is neither objective nor based on your expert opinion, and it doesn't judge the work that has been done. This is the same reason that if you had a judge on an olympic competition (diving, acrobatics, etc.) who would automatically give 10/10 to every athlete from his country regardless of the performance, you would call that out as being dishonest and biased, because he is supposed to be impartial. So, even though I think my snippet is objectively part of the top contenders, and even if I probably would vote for it if it was written by someone else, I consider it …

how do I access "bar" from something like line 43

You can't.

because we were only able to retrieve the variable from the public function, and you could do that anyway?

Yes, but the important thing is that you can only access it through the public function. This is especially important when you are setting the value of it. Imagine you have this class:

class Vector2D {
  private:
    double x;
    double y;
    double magnitude;
  public:
    double getX();
    double getY();
    void setX(double newX);
    void setY(double newY);
    double getMagnitude();
};

Now, at all times, you want the data member "magnitude" to reflect the magnitude of the vector, so, anytime you update the values of x or y, you need to recalculate the magnitude. If you allowed access to x or y directly, you wouldn't be able to do that, but by controlling the access to x and y through these public functions, you can do the following:

double Vector2D::getX() {
  return x;
};

double Vector2D::getY() {
  return y;
};

void Vector2D::setX(double newX) {
  x = newX;
  magnitude = sqrt( x * x + y * y );
};

void Vector2D::setY(double newY) {
  y = newY;
  magnitude = sqrt( x * x + y * y );
};

double Vector2D::getMagnitude() {
  return magnitude;
};

See how I can easily make sure that the value of "magnitude" is always consistent with the values stored in x and y, because anytime the user wants to modify those …

Welcome!

I've learned most of what I know from YouTube tutorials and some books.

Ditch the youtube tutorials, and make sure your book(s) is good. People who took the time to write a good quality book usually took the time to make their explanations clear and their approach suitable for the learner. People who put together a youtube video tutorial in an hour of spare time usually didn't.

Well, in almost all of those, they mentioned that it was poor programming practice to make all your data members public, inside of a class.

Roughly speaking, that's true. But, of course, as most "rules" in programming, they aren't black-and-white, it's the reasoning behind it that is important, and I think that is exactly what brought you here, so I'm glad for that.

If they are all private, how may I access it from different functions?

Well. That's the point of it all. The private/public/protected are access right specifiers and their purpose is to control from where the members can be accessed. When you create a class, all the data members and member functions of the class can be accessed by any parts of the implementation of that class. When you mark data members or member functions of a class as being private, you make it so that they are only accessible through parts of the implementation of that class, but not anywhere else. When you mark them as public, they are accessible from …

Only problem now is that it says:
Warning: resolving _GLHook_glAccum by linking to _GLHook_glAccum@8

This is only due to the fact that GCC (and other compilers) will generally disregard name-decoration (which is the @8 thing at the end of the name) when matching the symbols. So, it matches the symbol _GLHook_glAccum to the decorated symbol _GLHook_glAccum@8, but it warns you about it because it could be a mistake on your part. With decoration usually signifies that it is __stdcall, without the decoration it usually means it is __cdecl, which are different calling conventions. But these are not super strict rules (it's an old ad-hoc Microsoft rule (how surprising... (sarcasms))), so the compiler only generates a warning about it. To quell the warning you should have the decoration in your def-file symbols (right-hand-side of the equal sign).

I have to use the def file because if I don't use it, how will the original function point to mine?

Yes, renaming the functions to be exported is a valid reason for using a def-file. You could get the same effect otherwise (e.g., making wrapper functions (either in the cpp or header), or using the exported function names directly, i.e., without the GLHook_ prefix), but these are not nice solutions or even appropriate at all. But, renaming the functions in a DLL is not a very common thing that people do, that's why I said that "normally you don't need the def-file". In your case, it makes sense.

First things to verify:

• Are all your exported functions marked as having __stdcall as a calling convention?
• Are all your exported functions (or your whole code) marked with extern "C"?

If both answers are not "yes", then fix that before trying anything else.

Now the above will compile and work flawlessly in VisualStudio but in codeblocks it'll say "Cannot Export Symbols Undefined"..

If it cannot find the symbols to be exported, then that's a problem. First of all, you shouldn't need a def file at all when using MinGW/GCC (the compiler used by Code-Blocks), because GCC exports all global functions that are not marked as static (or don't fall in one of the "no linkage" or "internal linkage" cases). Long story short, everything is exported by default in GCC DLLs.

Second, it is usually easier to write a .def file by first generating it from the DLL or object files. MinGW has a tool for that, it is called "dlltool". You can then use the def file to rename or re-ordinate the symbols when remaking the dll. If you start from that, you should have no more issue of "Cannot Export Symbols Undefined.".

When I do export it in codeblocks, it shows 700 symbols in the DLLExport Viewer whereas the Visual Studio one shows 350.

That is because there are 350 symbols that you specified in the .def file and 350 symbols that are the automatically exported functions. While the MSVC version only …

You can try and run this:

#include <iostream>

float arr[] = {0.0, 1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0};

int main() {
  float* ptr = arr;

  // get the actual "address" that the pointer points to:
  std::size_t ptr_value = reinterpret_cast<std::size_t>(ptr);
  std::cout << "ptr = " << ptr_value << std::endl;

  // if you offset the pointer by 4, you get:
  float* ptr1 = ptr + 4;
  std::size_t ptr1_value = reinterpret_cast<std::size_t>(ptr1);
  std::cout << "ptr1 - ptr = " << ptr1_value - ptr_value << " bytes." << std::endl;

  // check this condition:
  if( ptr1_value - ptr_value == 4 * sizeof(float) )
    std::cout << "The difference between ptr1 and ptr is equal to 4 times the size of a float." << std::endl;

  // if you offset the pointer by 4 bytes, you get:
  float* ptr2 = reinterpret_cast<float*>(reinterpret_cast<char*>(ptr) + 4);
  std::size_t ptr2_value = reinterpret_cast<std::size_t>(ptr2);
  std::cout << "ptr2 - ptr = " << ptr2_value - ptr_value << " bytes." << std::endl;

  // check this condition:
  if( ptr2_value - ptr_value == 4 )
    std::cout << "The difference between ptr2 and ptr is equal to 4 bytes." << std::endl;

  return 0;
};

The meaning of my sentence was to explain the behavior of the above piece of code. Try it for yourself and you'll see.

The problem here is that when you add a number to a pointer, it moves the pointer by that number of objects that the pointer points to, not by that number of bytes. Say you have float* ptr;, then *(ptr + 4) is equivalent to ptr[4], meaning that it gets the float value that is 4 floats after the pointer address, not the float value that is 4 bytes after the pointer address. In OpenGL, the stride is specified as a number of bytes, so I assume your "Stride" variables are also in bytes. The way to solve this is by casting the pointer to a 1-byte type pointer, for instance, char*, then do the addition by the stride, and then cast it back to the actual pointer type to retrieve the value. As so:

for (int I = 0; I < TriangleCount; I++)
{
   cout<<"X: " << *( reinterpret_cast<const GLfloat*>(reinterpret_cast<const char*>(Pointer) + (I * Stride) ) ) << endl;
   cout<<"Y: " << *( reinterpret_cast<const GLfloat*>(reinterpret_cast<const char*>(Pointer) + (I * Stride) ) + 1 ) << endl;
   cout<<"Z: " << *( reinterpret_cast<const GLfloat*>(reinterpret_cast<const char*>(Pointer) + (I * Stride) ) + 2 ) << endl;
}

Notice also how the + 1 and + 2 are put after the cast back to const GLfloat*.

The last row should always be (0, 0, 0, 1). That's just the way it is. Look up homogeneous transformations (or Affine Transformations). The last row is there just so that a straight matrix-vector multiplication can be used, as opposed to a special function just for that type of matrix.

You can use the is_open() function on the ifstream. As so:

#include<iostream>
#include<fstream.h>
#include<string>
using namespace std;

int main()
{
    ifstream inFile;
    string inFileName;

    cout << "Enter a filename: ";
    cin >> inFileName;

    inFile.open(inFileName.c_str());

    if( ! inFile.is_open() ) {
        cout << "File could not be opened!" << endl;
    } else {
        cout << "File was successfully opened!" << endl;
    };

    system ("pause");
    return 1;
}

-1 prototype breadboard
-few sensors, you can get these online or from your local electronics store, in the UK we have a place called maplins that usually is good enough.
-two motors, one for forward, one for turning
-If you have lego technic raid your box for motors and gears and wheels

Let me expand a bit. Assuming you want to make a wheeled robot to go around like the rumba robot (robot vaccuum cleaner), by bumping into walls and turning in a random direction. The basic hardware would be:

• Prototyping: A solderless breadboard, with a kit of jumper wires for it.
  
  
  • Later, get a proto-board (also called "stripboard"), for the "permanent" circuits.
  • You also should get a starter kit of resistors and capacitors.
• Soldering kit (basically what you find in this kit):
  
  
  • Soldering iron, get two tips: a fat one and a thin one.
  • Solder: a roll of thin solder wires, and a roll of fatter solder wires is also nice.
  • A "helping hands" thing (stand with little clamps, very useful to hold things together).
  • Some wires and some wire cutters and clamps.
• A few useful proximity / touch sensors:
  
  
  • 2-3 IR proximity sensors (about 10$-15$ each).
  • 2-3 light-touch switches (for a physical bumper).
• Schmitt-trigger integrated circuits for all "digital" sensors (touch switches and if IR sensors are used as ON/OFF instead of analog distance read-outs).
• Two motors: differentially-driven (i.e., two wheels …

A simple robot like this (two wheels, differential steering, with some proximity sensors and possibly something else like a camera) is usually controlled with a microcontroller. Microcontrollers range from very simple to a smart-phone level of capabilities.

For very simple microcontrollers (uCs), they can be bought for as little as 20-30 dollars, but you'll need some electronics skills to integrate them into a robot (they are usually DIP-mounted, and require quite a bit of external circuitry like voltage regulators, pull-up/down resistors, and so on). If that is not something you are prepared or interested in doing, you'll have to go a step higher (in cost and capabilities). These simple uCs are typically programmed in C, and are rarely able to accomodate an operating system (or only a very simple OS, like FreeRTOS). Sometimes they allow C++ programming, but often with only limited capabilities (limited language support and reduced C++ standard library (or none at all)).

Then, you have mid-range uCs, like Arduino series. These are basically the same as the very simple uCs (Atmel AVR family), but they have more of the outside layer of electronics to allow for standard input-output protocol capabilities such as UART, TTL, PWM (and RC PWM), I2C, analog IOs, and maybe even encoder quadrature chips. And, with those you don't need to do much electronics besides soldering connectors, and mounting the chip with screws. As for programming, it's the same deal as for bare uCs, …

A little taste of the genius of George Carlin (RIP):

"I never understood national pride. You should be proud of things you achieved or acquired on your own, not for an accident of birth."

"It's called the American dream, because you have to be asleep to believe it."

"Military cemeteries around the world are packed with brainwashed dead soldiers who were convinced God was on their side... We pray for God to destroy our enemies, our enemies pray for God to destroy us... somebody's gonna be disappointed, somebody's wasting their f'ing time, could it be... everyone!"

"The best thing you can do to a kid is warn him about all the bu115hit that's to come, and teach him how to detect it."

"I have as much authority as the Pope, I just don't have as many people who believe it."

"I'm completely in favor of the separation of Church and State. My idea is that these two institutions screw us up enough on their own, so both of them together is certain death."

"Inside every cynical person, there is a disappointed idealist."

"The main reason Santa is so jolly is because he knows where all the naughty girls live."

"Weather forecast for tonight: dark."

"If a man is standing in the middle of the forest speaking and there is no woman around to hear him...is he still wrong?"

"Why do they lock gas station bathrooms? Are they afraid someone will clean them?"

"Give a man a fish and he will …

You can know what is supported using the glGetString function. This will allow you to get the version number and the list of supported extensions.

Overall, you should try to either stick to the core functionalities supported by the version you have, and possibly use supported ARB extensions. Basically, extensions move from vendor-specific (like NV), to general extension (EXT), to extensions accepted by the architecture review board (ARB), and then they become core functionalities on newer versions. Today, I think most hardware supports at least version 2.5 or 3.0 or later. Make sure that the header files that you are using to access the functions are up-to-date, and there shouldn't be much of an issue.

Normally, versions always remain backward compatible too.

As for actual game engines, they first isolate (behind abstractions) all the rendering code, so that they can easily swap out different rendering engines (OpenGL, Direct3D, and different versions of their renderers). Then, they decide what minimum capabilities they want their renderer to have, and that determines the minimum version of OpenGL or Direct3D that is needed to make that work (this would be the "minimum required DirectX or OpenGL version" that appears on the box). Finally, they code alternative rendering codes depending on what level of feature support the hardware provides (and according to those "graphics settings" that the player configures). So, yes, it is basically hard-coded, but you structure your rendering code such that you don't have too much repetition. For example, you have …

Have you looked into Vertex Buffer Objects (VBOs).

The glVertexPointer mechanism is older, before the time where it would be possible to transfer the vertices to the graphics card (in those days, you could barely store all the needed textures on the graphics card memory).

The easiest thing in this case is to just use a smart pointer, as so:

#include <ostream>
#include <fstream>
#include <iostream>
#include <memory>
using namespace std;

// a custom deleter that does nothing (no sure why the standard library doesn't have one of these):
struct null_deleter {
  template <typename T>
  void operator()(T*) const noexcept { };
};


shared_ptr<ostream> set_output_stream(int argc, char* argv[])
{
    // if there are any arguments, assume the first argument is the output
    // filename and try to open it.

    if(argc > 1)
    {
        return shared_ptr<ostream>(new ofstream(argv[1]));
    }
    else
    {
        // no arguments, so use cout (with no deleter)
        return shared_ptr<ostream>(&cout, null_deleter());
    }
}


void HelloWorld(ostream& outs)
{
    outs << "Hello World\n";
}


int main(int argc, char* argv[])
{
    shared_ptr<ostream> outs = set_output_stream(argc, argv);
    HelloWorld(*outs);
    return 0;
}

If you don't have a C++11 capable compiler, just use a boost::shared_ptr instead (or std::tr1::shared_ptr).

Do you have to use VC++? That's the main question.

Because if you can use MinGW/GCC, then there is no problem at all because it includes a make.exe program that you can use to build your project. Of course, you'll still have to worry about all the external dependencies, making sure their include/lib paths are correctly setup for Windows (because, obviously, it is completely different from Linux). And most MinGW-oriented development environments (like DevC++, CodeBlocks, Eclipse, etc.) allow you to easily load up a makefile-based project.

However, if you have to use VC++ (version newer than VC6), then you have basically no choice but to create a new project for scratch and add all the files. Visual Studio does have some facilities to create a project from existing code, but it is still largely a manual setup from scratch. Visual C++ used to have support for makefiles, but they dropped the feature (I'm pretty sure they did so on purpose). Basically, Microsoft doesn't want any inter-operability between their products and anything else in the world, that's just one example, and a prime reason why I never end up using Visual Studio because their build system is crap and it does play nice with anything else.

Finally, are you sure the code uses makefiles? Makefiles are often the intermediate output of another build-system (because you have to be a bit masochistic to create makefiles manually for a non-trivial project). Often, you'll have a build-system like cmake, auto-conf, bjam, qmake, and others …

Whenever you see code being repeated over and over, a light should come up saying: "I could probably use a loop for this!". For starter, you could easily condense your function into a single set of nested for-loops, as so:

void testFunc00(uchar * in, int len, uchar ** out) {
    int i = 0;
    for(int j = 0; j < 4; ++j) {
      for(int n = 0; (i < len) && (in[i] != '\0'); ++i, ++n)
        out[j][n] = in[i];
      ++i;
    }
}

You could probably add the maximum number of splits as a parameter too:

void testFunc00(uchar * in, int len, uchar ** out, int max_splits) {
    int i = 0;
    for(int j = 0; (i < len) && (j < max_splits); ++j) {
      for(int n = 0; (i < len) && (in[i] != '\0'); ++i, ++n)
        out[j][n] = in[i];
      ++i;
    }
}

Instead of if (*y == temp) to test if the element was found, you need to use this test:

if( y != a.end() )

Because if the element is not found, "y" will be equal to the end iterator, which means that it will be "not dereferencable".

Simply strip away the path from the names you get from GetModuleFilename or args[0]. As in:

#include <iostream>
#include <string>
#include <algorithm>

int main(int argc, char** argv) {

  std::string full_name = argv[0];

  std::cout << "Full name: " << full_name << std::endl;

  std::string exec_name(std::find(full_name.rbegin(),
                                  full_name.rend(),
                                  '\\').base(), 
                        full_name.end());

  std::cout << "Exec name: " << exec_name << std::endl;

  return 0;
};

Not only are you writing beyond the size of the array (i.e., because at the last iteration, i == N and thus, i+1 == N+1, and thus, the loop-expression becomes u[N+1] = 3*u[N] + 4;, and the one iteration before that (i == N-1) is also writing beyond the bounds of the array), but you actually don't need to use an array at all. In order to compute the expression within the loop, all you need is the value computed from the previous iteration. So, you don't need to store the entire array of values from 0 to N-1. Try to rewrite your code without using an array.

This is a dangerous question, things can easily escalate into a flame war.

It is very difficult to answer this question without knowing the specific kinds of differences you want to know about. There are countless technical and application differences between the two languages. You should probably start by reading both wiki entries, C++ and Java.

Here are some of the broad strokes (I'll try not to sound too much in favor of C++):

Main goals of the language:
C++: Performance and robustness.
Java: Safety and portability.

Syntax and style:
C++: Syntax is based off of C, with additional keywords for the plethora of additional features it has. Style varies, usually with the paradigm being used.
Java: Syntax is based off of C with most object-oriented syntax borrowed or heavily inspired from C++. Style is quite uniform, the Java-style is the de-facto standard style for "pure" object-oriented programming.

Typical running environment:
C++: Compiled to native machine code, runs as a native program on the target architecture (e.g., x86), must be recompiled for any different-enough platform (majorly different operating systems or architecture). Target platforms are anything from micro-controllers to super-computers and server farms.
Java: Compiled to bytecode (a kind of pseudo machine code), runs inside a virtual machine (Java Virtual Machine, or JVM), one Java "executable" can run on any platform (i.e., that is running the virtual machine). Target platforms are mostly consumer platforms (PCs, smart-phones, etc.) and servers (server-client applications).

Programming paradigm:
C++: Multi-paradigm language, the …

Did you include the header <algorithm>? Normally, this should be resolved by overloading. And you might also want to remove the using namespace std; statement. This remove function that you are getting is this one from cstdio. If you include the <algorithm> header, the overload resolution should be able to find the correct remove function.

The only compiler that currently supports "template aliases" (which is the name of this feature) is GCC version 4.7.0 and later (experimental). So, that's the compiler you need to install if you want that code to work. For Windows, MinGW has recently release a version with 4.7.0. As for Linux, you can look for up-stream repositories that carry bleeding-edge GCC versions, or you can build it from source (as I do).

You simply install MinGW to any directory (like the recommended directory C:\MinGW). Then, you go into Dev-C++, into the global options "Compiler Options". There, you should be able to set up the directory in which to find the gcc compiler, set that to C:\MinGW\bin (or the equivalent). There are also other directories to set up. Basically, watch for anything that references the old MinGW directories and switch those directories to the new installation (the sub-folder structure is the same for all MinGW versions). Verify that the "programs" names are correct (should be things like gcc.exe). And that's about it when it comes to changing the compiler to a new installation.

As for version 4.6, it allows some C++11, but not all. You can look at this table for a per-feature breakdown of the minimum version required. MinGW now supports version 4.7.0, that would probably be a wiser choice if you want to experiment with C++11.

Ok, so the solution to all your little mismatch errors is that the template <> is not needed before the function definitions. Sorry about that, it slipped my mind.

You also had a lot of errors in addition to that. I went ahead and solved a few of them, at least, to get it to compile. However, your implementation of the char* specialization is very wrong and is leaking memory all over the place, you will probably need to revise it entirely, but my guess is that you just didn't get to that point yet, now you are, with this corrected code:

#ifndef SIMPLEVECTOR_H
#define SIMPLEVECTOR_H
#include <cstdlib>
#include <iostream>
#include <new>
#include <iostream>
#include <cstring>

template <typename Type>
class SimpleVector
{
    private:
    Type* aptr;
    int arraySize;
    void memError();
    void subError();

    public:
    SimpleVector(int s = 0);
    SimpleVector(const SimpleVector&);
    ~SimpleVector();
    int size() const
    {
        return arraySize;
    }
    Type getElementAt(int);
    void setSize(int);
    Type& operator[](int);
    void push_back(const Type&);
    void pop_back();

};


template <>
class SimpleVector<char*>
{
    private:
    char** aptr;
    int arraySize;
    void memError()
    {
        std::cout<<"ERROR CANNOT ALLOCATE ! ENDING THE PROGRAM! ";
        exit(EXIT_FAILURE);
    }
    void subError()
    {

        std::cout<<"INVALID SUBSCRIPT! ENDING PROGRAM";
        exit(EXIT_FAILURE);
    }

    public:
    SimpleVector(int s = 0);
    SimpleVector(const SimpleVector<char*>&);
    ~SimpleVector();
    int size() const
    {
        return arraySize;
    }
    char* getElementAt(int);
    void setSize(int);
    char* operator[](int);
    void push_back(const char*);
    void pop_back();


};


template <typename Type>
SimpleVector<Type>::SimpleVector(int s)
{
    arraySize = s;
    if(arraySize == 0)
    {
        aptr = NULL;
        return;
    }
    try
    {
        aptr = new Type[arraySize];
    }
    catch(std::bad_alloc)
    {
        memError();
    }


    for(int count = …

I don't know much about online degrees, but I am a robotics engineer, so I might weight in a bit here.

First, you have to watch out when looking up online degrees because there are a lot of fake colleges or university, for-profit colleges and so on. Also, potential employers will be wary of any fishy-sounding degree, I know I would be.

But, there are respectable universities that do offer legitimate online / part-time degrees that would be as good as any. If you make sure of the legitimacy and quality of the online degree you pursue, there shouldn't be too much prejudice related to that, but I may be wrong.

In any case, having a lot of work experience, even at a "lower" level (technical tasks, etc.), is very valuable. Especially in robotics, there are hardware issues all the time and having people around that are very comfortable diving into that and solving those issues quickly is a huge bonus. In robotics, the bulk of the work is software, software, software, but when hardware issues hit (and they do very often) it is so nice to have people who are just as comfortable with a soldering iron as they are with a keyboard. The point that I'm making is that I would hire a guy (or gal) with an online degree and lots of hands on experience over a guy (or gal) with an honours degree (and immaculate record) and only short internship experiences, without even blinking. So, keep …

This is completely normal behavior. Floating-point numbers on a computer have limited precision. You're using float types which are also called single-precision floating point numbers, and the precision they have is usually about 7-8 significant digits. Your original number is around 30 and your error value is about 2e-6 which makes the relative error at about 0.67e-7 which is almost exactly the kind of error you should expect from using single-precision floating-point numbers (7-8 digits of precision). Get used to it, do not expect any floating-point calculations to be exact (they are only exact in a few rare cases). Doing numerical calculations on a computer is all about trying to limit the round-off errors (there is an entire field of computer science dedicated to this issue).

This also means that you should never to equal-comparison with floating-point numbers. That is, you should never do if(my_var == 0.0) but rather use this kind of test instead: if( fabs(my_var) < some_tolerance ) where you use some small tolerance value (e.g., 1e-5 to 1e-8 or so, depending if you use float or double).

The reason why 3D rendering code and libraries typically just use float as opposed to the more precise double is because precision is rarely a concern for rendering (it only needs to be as precise as the eye can distinguish, which is not precise at all) and speed is more critical.

First you're speaking about what you obviously don't seem to know.

I know a lot more than you think, it's just that I have an outside perspective, which is critical in being able to evaluate something objectively. Like with anything else, when you are too immersed into something, it becomes difficult to take an honest look at it, and religion is especially immersive and thus difficult to evaluate from an objective perspective when you are in it. Dismissing the opinions of someone giving you an outside perspective on a matter is never a good idea.

Second with all respect, Islam isn't Christianity or any other religion. Many principles in Islam do not apply at all to other religions.

Ohh, you'd be surprised how incredibly similar it looks from the outside. By the way, Christians would claim the exact same thing you do. In fact, I could probably take every word you wrote on this thread and simply change Allah for God and Muslim for Christian, and it would be really difficult to tell which is the original one. All religious folks claim there their religion has something unique, that their truth is deeper and more true, and that criticisms that apply to other organized religions don't apply to theirs, and so on so forth, but that is because they are too immersed in their religion and cannot take a step back and evaluate their religion the same way they evaluate others.

Third I'm not trying …

With my moderator hat on, I say:

Ignore Rash's post, he doesn't have the slightest clue what he's talking about, almost everything he said is wrong and misguided. Of course, you are free to use your code for personal projects or assignment submissions. And you still own copyrights to your code.

Sorry for the inconvenience (or scare), Rash is just throwing a tantrum against the terms of services. Why he would inflict this on innocent posters is beyond my comprehension.

With my moderator hat on, I say:

Ignore Rash's post, he doesn't have the slightest clue what he's talking about, almost everything he said is wrong and misguided. Of course, you are free to use your code for personal projects or assignment submissions. And you still own copyrights to your code.

Sorry for the inconvenience (or scare), Rash is just throwing a tantrum against the terms of services. Why he would inflict this on innocent posters is beyond my comprehension.

In your opinion what is a better language. C or C++.

It is highly dependent on what you do. C can certainly be simpler and hassle-free when doing some simple tasks (or low-level tasks). But C rapidly becomes difficult to manage on larger applications. I love software engineering, and C++ is awesome for that.

I mean this for operating systems to embedded software, deivce drivers, games and networking.

It is mostly a matter of size and complexity of the system. Embedded software and device drivers are usually very small programs and require quite a bit of low-level tricks (bit-wise operations, and setting hardware registers and interrupts), so, C is definitely the way to go (often the only choice, aside from assembly). Games and networking is almost entirely in C++ because these kinds of software are much more complicated structurally and require the kind of higher-level constructs that C++ allows you to do, but there are also other high-level languages used in those fields (interpreted or scripting languages, like C#/Java, PHP, Python, etc.). Operating systems (and compilers) are a bit of an exception here, most of them are entirely written in C (with some assembly), but these are large and complex systems that probably ought to be programmed in C++ (still, with many low-level components in C), but these are also very old and robust systems that cannot be changed overnight.

And is C++ so called OOP really going to be a bigger hit then C?

…

How useful is assembly? That's hard to say. Nowadays, it would be madness to write a large / complete application in assembly.

As far as I know, when it comes to writing assembly code, the only areas of application are in high-performance, low-level, and/or resource-restricted environments. I'm talking things like small micro-controllers (e.g., PICs) where assembly is the only option, and possibly in larger micro-controllers that usually support C (or BASIC) but assembly will be faster given the very limited resources. Then, there are things like hardware drivers and other low-level components (e.g., bus controllers, etc.). And finally, core functions that need to be highly optimized, usually small functions that get called an enormous amount of time like some kernel functions in an operating systems. I've also heard that there can be quite a bit of assembly programming in computer game programming, mostly in squeezing every clock cycle out of rendering code and programming shaders and other GPU processes.

All of these applications are highly specialized and you would probably end up having to learn assembly if you end up doing one of these things, but it is not worth learning to be proficient in assembly if you don't see a need for it in the very near future. Writing assembly is not fun, it's just very tedious to do. And it's not particularly difficult either (it's a very simple language after all!), it doesn't take very long to learn it, but don't do it for fun, only by necessity.

Let me retort a bit here. The point of view you expressed is exactly what I've always understood the Muslim's view-point to be and how I have perceived my muslim friends, but that's bad, and that's the problem, and thinking that this point of view is OK is even worse.

1- Islam encourages and orders Muslims to read and learn and discover everything around them in the universe. The first word that was sent to the Prophet of Islam, Muhammad, was "Read!". There are also many verses in the Qur'an that order Muslims to search around them and try to discover what's in human bodies, Nature and the whole universe. Learning science is part of Islam. And God will judge Muslims who don't learn if they can.

That's alright, but not good enough. Science is the practice of skepticism. It is not something you learn in a book or read about. The fundamental requirement to be able to learn about the world around you and to discover truth is to never believe anything if you don't have sufficient evidence to support it. You cannot build knowledge any other way, every "fact" or discovery has to be supported by enough evidence to be able to add it to the accumulated knowledge in science. So, it is good that the Qur'an encourages people to "search around", but if it doesn't teach you how to do this rigorously (i.e., the "scientific method"), then it is of no use. My guess is …

However, my question is, how is information about these variables stored in the binary, such that memory is allocated on the stack and the data segment for these variables?

Of course, this is highly dependent on the platform, so I can only explain in generic terms. The executable file will have two main parts: code-segment and data-segment. These will be loaded by the operating system into a read-only section of the virtual address space of that executable. Usually, there would be a standard fixed translation of addresses such that code can access read-only data-segments, such that addresses of read-only data can be hard-coded into the executable's binary code (say, for example, that all address starting with 0x40000000 in the executable will be mapped to the read-only data-segment by the OS). This is not necessarily so, but you get the idea.

For the static memory (for global non-const variables), the size of that data-segment can be determined at compile-time. So, this size value will either be stored in the executable such that the OS can retrieve it while loading the executable, and subsequently, allocate a chunk of read-write memory for that in the virtual address space. Again, the same kind of mechanism will map hard-coded addresses of these variables into their proper physical address in RAM (this is what "virtual address space" means).

For the stack, the overall size of the stack (the maximum size it can grow to) is something that you can configure with compiler options, the …

If a function is declared inline, its definition (implementation) must appear in the header file. Here are three equivalent options:

// in foo_header_option1.h
#ifndef FOO_HEADER_OPTION1_H
#define FOO_HEADER_OPTION1_H

class Foo {
  private:
    int bar;
  public:
    int getBar() const { return bar; };
    void setBar(int aBar) { bar = aBar; };
};

#endif

Or

// in foo_header_option2.h
#ifndef FOO_HEADER_OPTION2_H
#define FOO_HEADER_OPTION2_H

class Foo {
  private:
    int bar;
  public:
    inline int getBar() const; 
    inline void setBar(int aBar); 
};

int Foo::getBar() const {
  return bar;
};

void Foo::setBar(int aBar) {
  bar = aBar;
};

#endif

Or

// in foo_header_option2.h
#ifndef FOO_HEADER_OPTION2_H
#define FOO_HEADER_OPTION2_H

class Foo {
  private:
    int bar;
  public:
    int getBar() const; 
    void setBar(int aBar); 
};

inline int Foo::getBar() const {
  return bar;
};

inline void Foo::setBar(int aBar) {
  bar = aBar;
};

#endif

So, in all cases, the definition must appear in the header file. This makes sense because if the compiler is going to actually inline the function's code (put the function's code at the call-site, replacing the actual function call), then it must be able to grab that source code, and because each cpp file is compiled separately, when it compiles the caller's code, it must also have access to the function's code, thus, in the header file where it was declared.

In technical terms, a function marked as inline will have internal linkage which means that it will not be part of the exported symbols of a compiled object file, thus, unavailable to …

You are some piece of work my friend, or shall I say "troll".

Actually, that line can refer to a programming language

Right. And then you list 4 scripting languages. Bravo.. If I wanted to look stupid I could not have done better.

What, Shell Scripting? Remember this, Powershell is a form of Shell Scripting, and batch is also a form of shell scripting.

Powershell is fairly new, and is pretty much the same a bash shell. Batch scripting is an extremely limited shell, trying to do anything meaningful with it is a joke.

And for Python too, there is the win32 package, which is not for Linux or Mac

Python on windows is pretty bad, and lags behind. Using python in Linux (or Mac) is extremely easy and much more "native" than on windows. Also, Python is used extensively in Linux coding as the glue between lower-level C/C++ code. Many (if not most) libraries and applications in Linux have a Python layer at the top. I doubt this is the case in Windows due to the poor integration of Python in Windows.

Maybe because I dont know C or C++, but for Python with Windows, all you need to do is move the module to Python32/27/26/25, but for Linux, it is no easier than trying to build a nuclear reactor in a darkened room with watch pieces using only your teeth.

I'm no expert in Python, but I've dabbled with it. …

At line 106 of your last post, you need to allocate size for 1 more element than the current array-size. As so:

Type* temp = new Type[arraySize + 1];

That's what caused the run-time error.

Also, you should note that in your push-back function, you don't actually need to check for arraySize to be 0 because if it is, the for-loop at line 107 will not execute and the deletion of the aptr will not do anything because deleting a NULL pointer has no effect. For this to work, you have to make sure that whenever arraySize is 0 that the aptr pointer is also NULL. For example, your constructor should do this:

template <class Type>
SimpleVector<Type>::SimpleVector(int s)
{
    arraySize = s;
    // Check if arraySize is 0, if it is, then you set aptr to NULL and return:
    if(arraySize == 0)
    {
      aptr = NULL;
      return;
    };
    try
    {
        aptr = new Type[arraySize];
    }
    catch(std::bad_alloc)
    {
        memError();
    }
    for(int count = 0; count < arraySize; count++)
    {
        *(aptr + count) = 0;
    }
}

You should do something similar in the other constructor, as well as your resize and pop-back function should check if the new size is 0 and if it is, set the aptr pointer to NULL.

Once you can guarantee that whenever arraySize == 0 then aptr == NULL, then you can use the fact that deleting a null-pointer is OK (won't actually do anything), and simplify your destructor to this:

Your two functions in MyDetour.cpp must be declared with extern "C", and you should probably also add __stdcall since that's the calling convention for OpenGL functions on DLLs (and essentially every other DLL that exists too).

The header files are certainly not needed once the compilation is over (nor are they needed in unix environments). Normally, the DLL file should be required in order for the executable to work (if the DLL is actually used by the executable). With Microsoft products, it works as follows (for MinGW GCC it actually works the same as in unix environments (i.e., ELF)). You have basically 4 files that are important to explain this:

1. The source code for the executable, let's call it "main.cpp".
2. The header file that declares the DLL functions, let's call it "my_code.h".
3. The compiled DLL with all the functions, let's call it "my_code.dll".
4. A static import library generated while compiling the DLL, let's call it "my_code.lib".

When you write "main.cpp", you need to #include the header "my_code.h" to let the compiler know about the functions that you are using. Then, you must tell the compiler (or more precisely, the linker) that you wish to link to the import library "my_code.lib". This import library is where the linker will be able to find all the symbols (or hooks) for the "my_code" functions that you are calling in "main.cpp". This import library doesn't actually contain the code of the DLL, it just contains some initialization / finalization code to fetch and load / unload the DLL dynamically (while your executable is being loaded before it runs, and after it has finished running). So, all the functions (symbols or hooks) that the import library contains (which the linker …

@markwiering: Just a hint, if you want to quote a previous poster, you can copy the words into your post, then highlight it and click on the "Quote" button in the editor. Or, you can just add a > before the quoted text (which is what the "Quote" button does).

It does not matter for me or it is old or not. Every program I have made, can also be read by my Windows 7 computer upstairs.

There's no doubt that an old compiler is still a working compiler. If you are fine using it, then it's fine. But, there are drawbacks to using an old compiler. Compilers, like everything else, improve over time. Newer compilers are generally faster at compiling the code, can use more advanced instruction sets that are available on more recent machines, they have better optimization capabilities producing faster executables, and they have less bugs and more standard-compliance (i.e., there is standard-abiding C/C++ code that might not be compilable on older compilers because the people writing those compilers may not have got around to writing support for some of the features / requirements of the language's standard). The last point is especially true now since, as of the end of 2011, there is a new standard for C++ (called C++11, or used to be referred to as C++0x) which is only partially supported by bleeding-edge compilers (right now, if you do C++11 code, any compiler that is more than a few months old is …

It is starting to become an annoyance, it makes daniweb more of a forum entirely devoted to Linux.

I try to be neutral as much as I can. When I give instructions to people on installing a particular library or development tool or being able to link to it, or if I give instructions about dynamic libraries (DLLs or shared-objects) or multi-threading, and so on, I always try to give both Linux and Windows instructions. The only problem I have is that usually the Linux instructions are really simple (like an apt-get command and an additional compiler flag) while the Windows instructions are lengthy explanations of configuration settings through menus and what files to put in what folders, and environment variables to set, and bla bla bla. It's not my fault if Linux comes across in a much better light from a programmer's point of view.

I wrote a set of instructions the other day for setting up file-sharing and a source-code repository on my work-group's server. The Linux-specific instructions were at most a few sentences and a couple of commands. The Windows-specific instructions were several pages with links on tutorials to setup this or that. That's just one example, but that's the situation I see all the time, for every mundane little thing you do.

I'm tired of seeing #!/xxx/xxx/xxx at the start of every program.

I guess you mean #!/bin/bash. Most people would call that a bash script, not a program. And, by the …

For that purpose, if it were me, I would probably just write a program that grabs the source files (or just headers) from either the standard library implementation (GCC) or some other open-source library like Boost, and grab random bits and pieces of it. Nothing is going to look better than that, as "random code".

What is more surprising is that it even makes it as far to DrawIndexedPrimitives.

Your code to initialize the VBuffer and IBuffer are completely wrong. The only reason why using this temporary vector "solved" the problem, it because it displaced the memory corruption problem to somewhere that didn't matter as much. That's the nasty thing with memory corruption problems, is that most of the time "fixes" only move the problem elsewhere.

In any case, here is exactly the code that you should use to initialize your VBuffer and IBuffer:

// Here is the VBuffer copying part, (after creating it):

void *pVoid;
if(FAILED(pVBuffer->Lock(0, 0, (void**)&pVoid, 0)))
    return false;

memcpy(pVoid, &(sd.vert[0]), sd.vert.size() * sizeof(vertex));


// Here is the IBuffer copying part, (after creating it):

void *pvoid;
if(FAILED(pIBuffer->Lock(0,0, (void**)&pvoid, 0)))
    return false;

memcpy(pvoid, &(sd.facelist[0]), sd.facelist.size() * sizeof(face));

Another alternative if the above gives you problems (it shouldn't), which is this:

// Here is the VBuffer copying part, (after creating it):

vertex *pVertex; 
if(FAILED(pVBuffer->Lock(0, 0, (void**)&pVertex, 0)))
    return false;

std::copy(sd.vert.begin(), sd.vert.end(), pVertex);  // needs: #include <algorithm>


// Here is the IBuffer copying part, (after creating it):

face *pFaces;
if(FAILED(pIBuffer->Lock(0,0, (void**)&pFaces, 0)))
    return false;

std::copy(sd.facelist.begin(), sd.facelist.end(), pFaces);  // needs: #include <algorithm>

The error that you got comes from the fact that the copying methods you used were so corrupt that they filled the pVBuffer and pIBuffer with junk garbage values. So, as soon as you call DrawIndexedPrimitives, it would use these garbage values and fail with an error.

That part is an initialization list, it is used to construct the data members of the class. This is the preferred method to initialize data members (as opposed to assigning values to the data members in the body of the constructor).