Posts by mike_2000_17

Dumping a thread like this is not nice, but while we are at it. For outputting, I like this better:

//in some basic header of your software.

#ifndef DEBUG_VERBOSITY
#define DEBUG_VERBOSITY 5
#endif

#define DEBUG_NOTICE(X,Y) if(X <= DEBUG_VERBOSITY)  std::cout << __FILE__ << ":" << __LINE__ << " " << Y << std::endl;

//then in the code:
int main() {
  //..do something, then output an important debug notice:
  DEBUG_NOTICE(2,"the last operation failed! With error '" << error_message << "'")
  //..do other stuff, then output a not-so-important debug notice:
  DEBUG_NOTICE(8,"reached this point without segfault!");
  ... etc ...
};

Ton problème est que lorsque tu fais l'addition de plusieurs chaines de charactères, ses chaines sont converties en "String^" pour être additionner. Une fois additionné, tu as un String et non une chaines de charactère (char[] ou char*), et ils ne sont pas compatible implicitement. Donc, pour régler le problème, déclare la variable szSql12 de type "String^" et lorsque tu doit appeler "SQLExecDirectA()", passe comme paramètre "szSQL12.c_str()" à la place de juste "szSQL12".

Well in the above, the "&function" syntax is a function pointer which you can Google for. And the "hooks" that you are talking about is, from what I understand of your explanation, what is commonly known as "callback functions" which is very heavily used, especially in C interfaced libraries (such as most APIs). Look up these terms and check back on this thread if you want further explanation. Also, function pointers are not very popular anymore in C++ (unless it is for legacy with a C library or interface) because "function objects" are much more convenient, look that up too.

@yup790: Try this code, and you can hand it in as is:

#include <iostream>
#include <algorithm>
#include <functional>
using namespace std;

const char hello_world[] = {0x49,0x20,0x61,0x6D,0x20,0x61,0x20,0x63,0x68,0x65,0x61,0x74,0x65,0x72,0x21,0x00};

struct printOutFunctionObject {
  void operator () (int) {
    cout << hello_world << endl;
  };
};

struct null_iterator {
  bool operator !=(const null_iterator& iter) const { return true; };
  null_iterator operator ++() { return *this; };  
  int operator *() { return 0; };
};

int main() {
  for_each(null_iterator(),null_iterator(),printOutFunctionObject());
  return 0;
};

I would not particularly recommend the code Xuancong posted. First, the operator semantics are quite confusing and I doubt that the operator priorities make sense. When overloading operators, only overload the operators for which the semantics are kept (i.e. + always means an addition, - a subtraction, etc.), operators like >>= for the magnitude is just weird and will confuse people. Operator overloading is syntaxic sugar, nothing more, if it isn't obvious what the operator does than don't overload it.

Second, I'm not much of an expert, but I think all the asm code in there is probably not any better than what the compiler will produce with proper optimization flags (like SSE2 optimizations), it's not worth the trouble for you sfuo at this point, if even it improves performance at all.

What Lusiphur said is true for freeing or deallocating memory. Most of the time, for small applications that don't run for very long and don't use any OS resources (like threads, external processes, internet connection sockets, etc.) it will work fine without explicitly freeing all allocated memory, but not good coding practice though. But there are problems, such as if you are running an algorithm in a loop and in each iteration, you need an array to work with. If you allocate new memory for the array at the start of every iteration and don't deallocate it at the end of the iteration, you will get an perpetual increase in memory usage (e.g. say you have 1000 iterations and allocate 8000 bytes every time, you will wind up at the end of the algorithm with 8000000 bytes of wasted memory that will remain allocated for the entire time of the process).

It is important to distinguish memory allocation/deallocation from constructors/destructors. When you create an object, first memory gets allocated for the object, then the constructor is called to initialize the memory. At deallocation, the inverse happens, the destructor is called to do some clean up, and then the memory of the object is deallocated.

So, Why do we use destructors?
Well for simple classes where the data members are all simple stuff like primitive values (int, float, char, double, etc.) the destructor does not need to do anything and can be either empty or omitted. BUT, if …

The headers are not the code (well not the bulk of it at least). The headers declare what exists in the library such that you can use them in your code. So you need to include the headers in your code, successfully, to be able to use the code that is in the library. The purpose of the library is that all the code (cpp files) that is compiled in the library (which is much more than what is in its headers, which are mostly prototypes and trivial functions like get/set methods) doesn't need to be recompiled every time you compile your application, because it never changes.

What about this:

class vec3f
{
        private:
        GLfloat q[3];
	public:
	GLfloat& x() { return q[0]; };
        GLfloat& y() { return q[1]; };
        GLfloat& z() { return q[2]; };
        

	vec3f(){};

	vec3f( GLfloat x, GLfloat y, GLfloat z )
	{
		q[0] = x;
		q[1] = y;
		q[2] = z;
	}

	*operator GLfloat()
	{
		return q;
	}
}

>>Are there any good books about how C++ compilers works?

I used to know a good site that really went through compiler design and related tutorials very nicely (once had a wild dream of writing a compiler myself), but I can't find it anymore. I think this Stanford CS course has a whole bunch of lecture notes that go through it well. There are also more advanced courses on compilers there too.

But in this case, the problem discussed was more in relation to the Linker (which works after the compiler). I don't know that there is much public literature on Linkers (like "Linkers for dummies", lol) because the basic idea of it just boils down to taking the list of symbols the compiler produced, look through the compiled code for undefined external references (functions that are not found in the compilation unit and thus, need to be linked to some other object file / library / DLL), and then doing symbol look-ups and associating the external references to the functions that were found in external libraries. Of course, there is much more to it, but that basic knowledge is enough for practical purposes when coding (you would really only need to know more if you plan to work later on designing compilers and linkers yourself or on some other high-end CS field, in which case you would have to learn much more than what books or textbooks could tell you about it).

Well, I did a bit of image processing, so I know the basic theory. I can't explain it all but I can give some keywords and methods for you to look up.

First, the problem of resolution, cropping, geometric disturbance (rotation translation scaling etc.) is pretty trivial to solve really. What you need to do is re-sample the image with increased resolution and geometry correction. The re-sampling is done with a bi-linear interpolation (or better) of the surrounding pixels. Say you double the resolution, it means for each 2x2 pixels square you need to make a 4x4 square, so for each of the new pixels you figure out where the four closest original pixels are (four corners) and do a bi-linear interpolation to get the color (or gray-scale) of the new pixel. For the geometric correction, that's just a mapping from the position of a pixel in the original image to the position of the pixel in the new image. Usually the mapping is: constant terms = translation, linear terms (x_new = A*x_old) = scaling, bi-linear terms (like x_new = A*y_old) = rotation + scaling, ... and it goes on for higher order terms like correction of fish-eye effect, etc.

Then for the comparison, well normally people use cross-correlation to compare two images. The basic idea is pretty simple. If you have two images that are the same, if you multiply each pixel-value (color or gray-scale) from the same position together and add them all up, you get …

From my experience, this looks like a memory corruption problem. Maybe playing with valgrind can help you. Also, try outputting the pointer addresses you use. verify each dynamic memory allocation to make sure you never use an uninitialized pointer. Also check bounds on for-loops and stuff, make sure you are not writing memory out of bounds. Valgrind will help you with all that.

When you make changes until the bug disappears, and then roll-back and it doesn't reappear, it probably has to do with the fact that the memory pattern of your program is slightly altered so it no longer causes a visible problem, but it doesn't mean the problem really did disappear.

Is this a multi-threaded application? Pseudo-random-like errors often occur when the program is multi-threaded and the memory is not properly shielded with mutexes.

You have to specify the correct include path in your own stuff too. This error is not in the FTGL library which compiled successfully. Once compiled, it no longer needs to find the includes for the .lib, but it needs to find the includes that you use in your code and it doesn't find it because the include path is not complete or incorrect.

Are you kidding.. it's been twenty days and you still haven't had to hand-in your assignment, such a trivial one too. Man... talk about easy grades..

here it is.. so that you stop crying about it:

#include <iostream>
#include <cmath>

int main()
{
  float B,N,I,R;
  cout<<"Enter the no of the turns,N: \n";
  cin>>N;
  cout<<"Enter the intensity of current,I: \n";
  cin>>I;
  cout<<"Enter the magnitude of Resistance,R: \n";
  cin>>R;
  int x;
  cout<<"Distance from the center of the coil to the point where field is to be calculated,x: \n";
  cin>>x;

  B = N * I * R * R / (2.0 * pow(R*R + x*x, 3.0 / 2.0));

  cout<<"The Magnetic field at the point is "<<B<<"T";
  return 0;
}

see... all I had to do is put that one line I posted earlier into your code. How hard was that for you to do?
In the future, you should know that putting many sss after pls only convinces people that for you, begging is easier than reading, thinking and learning. In other words, it tells people: I'm lazy and stupid, please pity me enough to give me a free-pass. Well I do pity you, and the above is the only pocket-change I can give you.

Ok, well I can put a bit of an example of a binbag: (without OS-specific flags, I don't want to be bothered, that's for you to work on)

#define DEFAULT_SIZE 4096 //or whatever.. like the size of the IP header.
class oBinBag;
class iBinBag;

class serializable {
  public:
    void save(oBinBag& B) = 0;
    void load(iBinBag& B) = 0;
};

class oBinBag {
  private:
    unsigned char* buffer;
    int pos;
    int size;
  public:
    oBinBag() : buffer(new unsigned char[DEFAULT_SIZE]), pos(0), size(DEFAULT_SIZE) { };
    ~oBinBag() { delete[] buffer; };

    oBinBag& operator <<(uint32 value) {
      //say, MSB first:
      if(pos > size - 4) {
        unsigned char* tmp = new unsigned char[size *= 2];
        memmove(tmp,buffer,pos);
        delete[] buffer;
        buffer = tmp;
      };
      buffer[pos++] = value & 0xFF000000;
      buffer[pos++] = value & 0x00FF0000;
      buffer[pos++] = value & 0x0000FF00;
      buffer[pos++] = value & 0x000000FF;
      return *this;
    };
    oBinBag& operator <<(uint16 value) {
      //say, MSB first:
      if(pos > size - 2) {
        unsigned char* tmp = new unsigned char[size *= 2];
        memmove(tmp,buffer,pos);
        delete[] buffer;
        buffer = tmp;
      };
      buffer[pos++] = value & 0x0000FF00;
      buffer[pos++] = value & 0x000000FF;
      return *this;
    };
    
    //etc.. for as many primitive types you need, but watch out for ambiguous overloads.
    
    oBinBag& operator <<(serializable& value) {
      value.save(*this);
      return *this;
    };
};

// the same but in reverse for iBinBag (with >> operators)

// Then, a typical struct like IPHeader, lets say:
class IPHeader : public serializable {
  private:
    uint8 headerlength; // header length
    uint8 version; // version
    uint8 tos; // type of service
    uint16 packetlength; …

I see two things that could be happening that makes it compile without error in VC++:

1. VC++ might actually mangle the names differently according to return type, the standard allows it even though it really serves no purpose because overloaded return type are not supported, so who knows, maybe for the VC++ linker these two functions are not ambiguous at link-time.

2. Most probably, the linker looks into one object file at a time to resolve its external symbols and once it finds a match it is satisfied and does not look any further, such as to see if there is a multiple occurrence of the symbol (which is a bit of a waste of time). This actually happened for me with GCC, there was an old version of an object file put in one lib and the newer one in another and I was getting a ton of seg-faults and stuff because the linker was linking the old version and was not complaining that there were all the same external symbols in another library (just because of the order they were send to the compiler). But still, in the same module, the multiple occurring symbols should be detecting during the construction of the symbol table, unless VC++ does not make a lib-wide symbol table when all the object files go into an executable.

I don't mean to interrupt, but usually when you want a really robust binary interface for a byte-stream. You don't cast, or stringify, or pack/pragma, or what give you. You implement a binbag with off-the-hook protection from cross-platform, cross-compiler, cross-compiling-option.. the whole shabang. Implement the binbag's interface on the model of the std::iostreams (with those nice << >> operators) or like Boost Serialization. Then you write a save / load, or send / receive, or pack / unpack, or whatever you like to call it, that will serialize or un-serialize the data by packing it into or extracting from the binbag. This way you put all the nasty conditional compilations that you will need for ensuring off-the-hook binary-compatibility, all in one place (the binbag implementation).

Just my humble input, take it or leave it.

Well, since your original code is so far off, and sfuo already posted a valid solution, let me just post a slightly better one that applies if you don't care about the print order at all:

void printAllFactors( int in )
{
	//start at 2 if you want it to not show 1 and "in" as a factor  
	int hi = in; //declare a variable for the higher factor in the factor-pairs.
        for( int lo = 1; lo <= hi; ++lo ) //start the counter at 1 and loop it until the higher factor reaches the lower factor
		if( in % lo == 0 ) { //check if lo divides evenly into the input number
                        hi = in / lo; //compute the higher factor of the pair
			cout << lo << " " << hi << " "; //print the factor-pair
                };
	cout << endl;
}

Agreed. It is also good practice to play around with the example codes. For example if you are not sure why a particular line code is there or why the author does something in a particular way, you can just change it and see what happens. It's good to also skim through the book, to get an idea of what you are going to learn from it, and start an ongoing project that incorporates most of the concepts of the book, and develop the parts incrementally as you learn the new concepts. This way you get a bit of independent problem solving skills rather than just a theoretical understanding of the concepts, it helps to really understand the "why" and the "what is this good/useful for".

So I would suggest you take the examples from the book, compile them, tweak them around to make sure you understand everything about it that might be unclear from the book's explanation, and once you are comfortable with that "lesson" try to incorporate it in your ongoing "bigger" project if applicable (but don't make the project too big at first, you can always switch to a bigger project later, if you accomplish everything).

If you have any problems along the way, you know where to post a thread to get help ;)

Then use RAII (Resource Allocation Is Initialization). Make a constructor for Stack and SortedList that takes both data members it needs (data and link). This way, you do:

Stack* new_address = new Stack(number,NULL); //BTW, just a hint, NULL is probably not what you want link to be set to for the linked list to work.

You might have a dangling newline on the cin, so when you try getline it returns an empty line before you even have time to enter anything. Simple solution, replace the "cin >> answer;" part with:

cin.ignore(); //this will ignore any newlines that are on the input buffer but not yet red.
getline(cin,answer); //then read the line.

Well MSDN says this:

The classes in <strstream> are deprecated. Consider using the classes in <sstream> instead.

And www.cplusplus.com has no mention of strstream at all, it seems to have vanished from their standard library reference documents.

It appears also that strstream uses char arrays in the underlying implementation while stringstream uses std::string, which is better, of course.

Simple.

If you are implementing a Stack as a linked list, then every link in the list has to be a Stack too (and similarly for a SortedList). So the new link that you make with "new LinkedList" (which is of course illegal) you can create with "new Stack" or "new SortedList". Then, you will actually be able to access the protected member "link" in that newly created Stack or SortedList because the compiler knows they are of that type because you just created it. To help, if it doesn't work (i.e. your compiler is not clever enough), you can declare "new_address" as "Stack*" or "SortedList*".

There are some tools for "code refactoring", I have looked for good ones that are free or opensource, but to no avail. Visual C++ has apparently very good tools for code refactoring, but I have not used them.

In this case, you want to use a serialization library like the one in Boost to do those stream in and stream out functions. There are also plenty of other libraries in Boost that can be useful for this like the preprocessor library, the template meta-programming library (MPL), or even the group Bind/Lambda/Phoenix/Spirit. You'll probably will find what you need there, try not to use scripts as code factories, the preprocessor and templates are much better options.

the (int) cast is from C, and is not recommended in C++ for good reasons. Use the "functional" casting:

//check the video info header
Width  = int(&pVideoInfoHeader->bmiHeader.biWidth);
Height = int(&pVideoInfoHeader->bmiHeader.biHeight);

//break point here

But in this case, long is implicitly convertable to int, so the cast is useless anyways.

Ok, well change the constructor parameter aPeople to the type Person** instead:

XYZ(int aCount, Person** aPeople)

The [] notation of arrays is a remnant of C, and C++ compilers don't deal well with it.
And I was wrong about the const there, if a const should be any where, it's at the end to indicate the pointer is constant, "Person** const aPeople", but don't worry about that.

I think there is no need to dig up a place in the C++ standard where it says something like: "a class Foo derived from class Bar cannot access the protected members of Bar from another object of type Bar or any other of its derived class, including Foo." Because this is obvious. The "protected" access rights are limited to the instance of the derived class. In other words, a Foo object can access ITS OWN protected members that IT GOT from ITS inheritance of Bar. For any other object that is not the "this" object, protected members are inaccessible, just like if they were private, as far as Foo is concerned or any other derived class for that matter.

This is required for encapsulation. It would be far too dangerous to allow all objects of classes derived from Bar to be able to temper with the protected members of other objects inheriting from Bar. Think about it, if that was allowed, you could easily make a dummy class derived from Bar, to do some operation on the protected members of all the other classes derived from Bar, that totally breaks encapsulation.. As they say, "with great power comes great responsibility", well a golden rule in programming is "when it is easy to do the wrong thing, don't trust any programmer to do the right thing, especially not yourself!" and access right is one of the features of C++ that tries to give you tools to help you help …

The "name" of the semaphore is, in your code, the string "B", not the identifier namedsema2. Of course that variable is in Thread1 and will be undeclared in Thread2.

This is how it should be:

class Thread1 : public PThread
{
public:
    Thread1() : PThread(8096, PThread::NoAutoDeleteThread) 
    {}

    virtual void Main()
    {
        PNamedSemaphore namedsema2(0, 1,"B");
        namedsema2.Wait();
        std::cout << "Signal from Thread2 received!" << std::endl;
        // create a NS for the other thread to open
    }
   
};

class Thread2 : public PThread
{
public:
    Thread2() : PThread(8096, PThread::NoAutoDeleteThread) 
    {}
    virtual void Main()
    { 
      PNamedSemaphore namedsema2(0, 1,"B"); //sending the same name "B" will make both PNamedSemaphore objects refer to the same semaphore.
      namedsema2.Post();
    }
}

Oh... small piece of code, lots of problems:

struct Person
{
    char* name; //this is a pointer to a char (or array of char, with null-termination)
    int age;

    //For good practice, use parameter names that don't conflict with data member names.
    Person(const char* aName, int aAge) //notice the "const" on aName to make it illegal for this constructor to change aName.
    {
        //this->name = name; //This is memory-horror. Setting the pointer name to aName does not copy the memory content of aName (i.e. the string).
        //This will copy the name: begin{
        int length = strlen(aName);
        name = new char[length+1];
        strcpy(name,aName);
        //}end
        age = aAge; //notice, no need for this-> when names are not ambiguous.
    }
    //It is unacceptable for a class or struct to hold a pointer without cleaning its memory upon destruction, with this:
    ~Person() {
      if(name)
        delete[] name;
    }
}

struct XYZ
{
    int count;
    //Person* people[]; //Cannot reseat an array [] type, or at least not on standard compilers. That's why "this->people = people;" caused an error. 
    Person** people;

    XYZ(int aCount, const Person* aPeople[]) //notice it is fine to send it as array[] in parameter list (but add const).
    {
       count = aCount;
       //this->people = people; // << Error here. //Again, same memory-horror as above.
       if(count) {
         people = new People*[count];
         for(int i = 0; i < count ; ++i)
           people[i] = aPeople[i];
       } else {
         people = NULL;
       }
    }
    //Again, ALWAYS CLEAN THE MEMORY!
    ~XYZ() {
      if(count) {
        for(int i = 0; i < …

Of course you can! That's the whole point of semaphores: to synchronize threads. A named semaphore is convenient because all you need to do is call sem_open with the same name and you get the same semaphore for two, three, four, or a gezillion threads.

From this link:

A named semaphore is identified by a name of the form /somename. Two processes can operate on the same named semaphore by passing the same name to sem_open(3).

These are the faulty lines:

out.write("\t",4);
..
out.write("\n",4);

Where is the 4 coming from? The length of "\t" is 1. The "Wa" is probably corresponding to some memory that is stored after the literal "\t" and "\n" which both take 2 bytes (one is \t or \n and the other is the null-character) so the compiler probably reuses the same chunk of memory so the same two extra characters "Wa" appear in each case. So "Wa" is probably the first two characters of another literal string somewhere near in the code.

Well, I used to work with C++Builder (the older versions, like 5 to 7) and I have always like it much better than the Visual C++ versions of the time. I don't know how much both have changed since and how they compare now. But I would say that C++Builder is much better integrated with the GUI design and the VCL/CLX component libraries (or whatever they call it now) really kick some serious butt. Especially since Borland is a RAD company (Rapid Application Development) and most of their business is about Database integration into large management-style software. I haven't worked a lot with Databases, but I remember a tutorial in C++Builder which was about creating an almost-fully-functional "Excel" software without writing a single line of code, only using VCL's plug-and-play implementation with Databases. And it also comes with all sorts of separate advanced Database tools, that I never used or know much about. Another nice feature of C++Builder (at least the older versions) is that the Borland compiler is built on top of a Delphi compiler which is immensely faster then other C++ compilers (code that I compile now with GCC in about 45 minutes, I used to compile with C++Builder in about 30 seconds).

Yet again, don't think that Visual C++ 2010 does not have a ton of awesome features too (especially code re-factoring tools) and probably links well with Microsoft stuff, if you can bare the pain of it... I'm a Linux guy, so I use KDevelop …

>>Just as an off point about my cone class so far, i think its not a bad job, whats your opinion? Anything you would suggest/criticise? or is it ok for a beginners first shape class?

Well, for a first shape class it's very nicely done! Of course.. on a more advanced level there are quite a few things that could be improved: (and I put them in order of priority, given the level you are at now, you should probably not worry about the last two points)

First, you probably want to have a base class or just an interface like "renderable" or "visible_object" interface for a virtual render() method. This way you can use polymorphism to store a list of visible objects or shapes of any kind, and render the entire "world" by traversing that list.

In a best practices' perspective, this cPyramid class is a very good candidate to use RAII (Resource Allocation Is Initialization). This means that in this case you don't really need InitGeo(), InitColor() and SetTexture(), because the first two will be more easily done together and the third one is trivial. Thus, you can put all their implementations together in a parametrized constructor for cPyramid and don't provide set/get methods. This way, when you create a new cPyramid, you define permanently how it is (width, colour, texture, etc.) and if you need to change it, you delete it and create a new one. That's the essence of RAII in the sense …

Pretty nice! But I have a few things to point out:

First, gcc complains with this code because of those "typename typedef .." statements at the beginning of the MergeSort class. These don't make sense as you posted them, and I don't understand why your compiler would not complain. As you put it, it reads "I state a typename from defining the type std::vector<Type> as ArrayType" when it should read "I define a type from the typename std::vector<Type> called ArrayType". This corresponds to this code (just inverting the keywords):

typedef typename std::vector<Type> ArrayType;
	typedef typename std::vector<Type>::const_iterator constItrType;
	typedef typename std::vector<Type>::difference_type DiffType;

Then, well there is a bit of useless copying of vectors in your implementation. I know, a good compiler can do a lot of the optimization for you, but in this case it might be worth eliminating temporaries a bit more. After all, the purpose of MergeSort is to be efficient.

Finally, in _mergeSort, erasing elements from the vector "lhs" and "rhs" is useless and might very well destroy your performance by adding a O(N) complex calls in the middle of your merge loops, I haven't worked out the math or a test-benchmark, but I doubt it remains O(NlogN). Furthermore, allocating capacity for the result vector with a simple reserve() call will also make your push_back calls guaranteed to be O(1).

So, my mods to the two _mergeSort and _sortIt methods would look like this:

ArrayType _sortIt(constItrType begin, constItrType end)const{
		if(end - begin  < …

As far as I know, this code is fine on a standard implementation. It seems that the underlying problem is that aCC doesn't have a "less" comparator for string types. Try implementing your own comparator for the string class and pass it as template argument in the declaration of _map2.

I can't help much, but I can say that usually what you are referring to is called an "edit box" not a text box. That might help you in your web search.

I'm not going to be able to help with the details of the asm code (is there a reason why it's programmed in asm?) but I have a bit of know-how on serial ports. Did you try to implement the receiver in C++ code? From what I see (from the comments of the asm code) there is no parts that set up the receiver's serial port config (baudrate, parity, checksum, etc.). This needs to be in the receiver code too, just like in the transmitter's code.

One way to avoid going into hyperterminal to set up the port all the time, is by setting it up in the Windows Device Manager (I know it's not a nice solution, but at least you don't have to reconfigure with hyperterminal all the time).

Why do you need two operators <<? I mean if you put the code for the second one into the first one, you will only need to do "fileOut << d;". Moreover, the second call "<< d.beamlets" is not going to work because beamlets is a private member of the DCP class. If you need the second << operator (for the vector of beamlet), then just call it inside the first one, i.e. "return out << dcp.beamlets;".

Then, this piece of code seems really weird to me:

if (it!=b.end()-2) out1 << it.left << "," << it.right << ",\n";
	    else out2 << it.left << "," << it.right << "\n";

I don't think that "b.end()-2" is meaningful at all, most probably, it is undefined behaviour, so try to avoid it. Use indexing instead of operators to check where you are in the array. And what is this piece of code supposed to accomplish? The comma at the end of the first line, in ",\n", is useless, and this way, you don't need this conditional at all.

Other then that, it seem fine. BTW, these are NOT nested classes, these are just two friend classes. But maybe beamlet should be nested in DCP.

In your InitGeo function, you call sinf(theta) several times and theta IS IN DEGREES! That's your problem. use the angle variable instead. In the future, it might be a good idea to get used to using only radians for everything, degrees are meaningless and useless most of the time.

The rest looks fine to me.

First, pArray should be declared as unsigned char* (no double stars).

Allocate for pArray with new unsigned char.

If you are reading the characters as each being an individual number from 0 to 255 in binary format (since this is how you open the file), then forget about adding a null-character at the end or casting to char* with cout.write(), yes it will turn your array into something like a C-string that can be printed, but the output will be ludacris, random gibberish. To print out the numerical values, output them within a for-loop and a cast to (int). If it is a string in the file, then load it normally and use char*.

It worked fine for me, with correct output.

I'm not sure how much I can help. Aren't IP cameras just using UDP or TCP? The IP camera should come with some demo application (usually running on a web browser) that will start the camera, allow you to set up the settings, and display the live stream. They should also come with a driver (usually in C or C++, or a DLL/.so) to use it. If not, check the data sheet or programmer's manual or whatever documentation they have on the company website and you should find what commands do what and how to receive the video streaming. So your program will need to connect to the server (IP camera) with just a normal internet connection but to some local IP address and then send/receive packets as specified by the company. There may be some generic tools / libraries for dealing with IP cameras, but I don't know any and when I had to deal with an IP camera, the provided software was good enough for my purposes. Your best bet is to contact consumer support at the company after searching their website thoroughly for the proper manuals.

If it does print "End of file", then what you need to do to close the window is to click on the X in the upper right corner. Once it reaches the end of the program, if the window doesn't close by then, then there's nothing to put in your program that will close the window.

Well, the line "getch();" is going to wait for the user to type a character before exiting the program. Remove it and the program will exit after printing "End of file!" and the console window will close.

Yeah, easy. A string is a list of chars. All you have to do is:

char recvbuffer[512];
MessageBox(hWnd, recvbuffer, "Character to String");

It works fine on gcc in linux. Try using Code::Blocks instead of Dev-C++, which is outdated and has several issues with Windows Vista/7.

Download and install the latest version with MinGW the file named "codeblocks-10.05mingw-setup.exe" from the links here.

it must be a typo of some sort, because this code is fine and should compile. This will compile (I tested it):

#include <iostream>

struct structA {
  int val;
};

struct structB {
  double val;
};

class classA {
  public:
    int function(structA * ptrA) { std::cout << "function_A called!" << std::endl; return 0; };
    int function(structB * ptrB) { std::cout << "function_B called!" << std::endl; return 0; };
};

int main() {
  structA a; a.val = 3;
  structB b; b.val = 1.0;
  classA obj;
  obj.function(&a);
  obj.function(&b);
};

Tested it with g++ -std=c++0x and g++ -std=gnu++0x, in both cases:
error: cannot convert ‘<brace-enclosed initializer list>’ to ‘const int*’ for argument ‘1’ to ‘void someFunction(const int*)’

I added const because otherwise it would never work for sure.

First logic feature to see is that it is always symmetric about the central value in one sequence, so you will probably just need to store or compute one half of each row (from start to middle) and repeat in reverse for the remainder of the row (taking into account even and odd number of elements).

The second logic feature to see is more evident in the normal display of the pascal triangle (forgive the ASCII art):

1
           / \
           1  1
          / \/ \
          1  2  1
         / \/ \/ \
         1  3  3  1
        / \/ \/ \/ \
        1  4  6  4  1
            ....

From this it's clear that the operation that joins a \/ segment is the addition. So like in ganesh's pseudo-code, the basic idea is to add two adjacent elements of the previous row to get the corresponding element of the next row (except for the first element which is always 1 and the centre element of an odd-row which might be twice the element closest to centre of the even-row above it).

Show us some code of your own, and we can help you further.

Well... TR1 is part of the C++ standard libraries (and STL). And those smart pointers are part of TR1. So that would not violate your rule of minimizing external dependencies (which I applaud you for, because I think it is paramount to limit external dependencies).

Boost is essentially a cross-platform, peer-reviewed, open-source collection of libraries which is considered as the anti-chamber of the C++ standard library and members of the standard committee and other prominent members of the C++ community are peer-reviewers for it. So if there is any external dependency you can easily live with it's this one.