Posts by mike_2000_17

@bibhay:
>> and its not random at all
Of course it's not random, NOTHING is random on a computer! We, advice-giving posters, would be very retarded if we even thought so (did you see us mention it to be random anywhere in the thread?). It's UNDEFINED BEHAVIOUR, meaning the standard specifications alone are not enough to predict the result, it's either compiler-specific (and compiler-option-specific) or OS-specific... but of course, not random! Just completely undependable and thus to be avoided for robust coding.

BTW I'm not a computer science student, I learned everything on a try-it-myself basis (counting the LOCs in the millions) and I agree that the nose-in-the-textbook approach is almost completely useless. But that's no reason to be a snob to those who are learning and trying to understand what is happening in their _trial_ / example codes.

Man... this is just a typo:

//this line:
if ( triangle_test ( point1, point2, point3 ) == 1 )
//should be this
if ( triangle_test ( point1, point2, point3 ) == 0 ) //notice 0 not 1!

Aranarth is right, this test for triangle only makes sense if you have three sides to start with, not three points. For three points, it will never be greater.

So with both these corrections. I think you'll be set.

Well, think by representing the operation for small 2x2 and 3x3 matrices, you can see the pattern emerge:

//say vector<double> q is some 2x2 matrix then
qt = {q[0],q[2],q[1],q[3]};
//say vector<double> q is some 3x3 matrix then
qt = {q[0],q[3],q[6],q[1],q[4],q[7],q[2],q[5],q[8]};

For a (faster) limited-memory way, well there is a way to program this as a swapping chain, I think I've seen that somewhere, sometime ago. I think the basic idea is: you start with the first value that will have to move (in your example, the "3", at first row, second position from the left), figure out where it's supposed to go, hold that value as temporary, store the "3" at that place, and start again by figuring out where that new value should go (the one in temporary) and repeat until you come back to the original spot. I'm not sure this is exactly how it works, if it really visits the entire matrix and comes back to the start, but I think there is a way to do it along these lines.

EDIT: I just tested the above, and it works indeed!

Well, I agree with jonsca, use a while loop. You can also use "continue" to come back to the start of the while loop from anywhere inside the loop.

If it really is not going to work with a while loop, do everything you can think of to make it work... and if all else fails, C++ still supports the infamous "goto" statement.

>>Also why did you initialize front to -1?
Because that's the value before 0.

>>Pass-by-reference?
Well as the compiler tells you to:

void node<T>::addNodeAtFront(const T& value, node<T>*& frontNode) //notice *&, not just &

glad I could help!

Well one problem is:

double r=(c.x-a.x)/ab.x;

This can be a divide-by-zero.

This triangle test can be done without a division. Are you familiar with the cross-product? If two vectors have a cross-product equal to zero, they are collinear, and thus cannot form a triangle.

@AkashL: The auto_ptr will help because it will make sure the "paramTime" in this case is deleted before main() exits, but it is not ideal because, as you said, it is not reference counted, so if the pointer is copied to other functions and stuff, it will get deleted at the first scope that it leaves and its copies will be pointing to a deleted object (very bad, of course).

The unique_ptr is better for two reasons. First it is non-copyable, it's guaranteed that it will not be sent anywhere that is outside the original scope, and will be automatically deleted at the end of the scope (as for that auto_ptr). Second, a unique_ptr is packaged with a deleter (optional parameter to the constructor of unique_ptr), this guarantee that the delete operator used to free the resource is the right one (this is extremely useful for cross-module implementations, where multiple heaps are involved in the overall application).

So the conclusion is that auto_ptr is not very safe in general. shared_ptr/weak_ptr and unique_ptr are more useful for the copyable-reference-counted case and the non-copyable case, respectively.

@bleedi, if you are using linux, try valgrind to diagnose memory leaks and other memory-related issues.

>>error C2582: 'operator =' function is unavailable in 'Cord'
This means there is no default assignment operator for type Cord, you need to implement one. This error would not happen in C++.

RANT ALERT!
This is C++/CLI, not C++. So you will probably find better luck looking for answers by restricting yourself to the domain of C++/CLI. Because the above syntax and the error you get have no relationship to C++, and that's probably why no one else has answered yet. C++/CLI is a completely different programming language, and yet another perverse attempt by Microsoft to get .NET to swallow all the code in the world! But they are only driving all good programmers further and further away by these C# and CLI attempts at seducing C++ programmers, all they accomplish is getting inexperienced programmers do develop a useless skills at C# and CLI, while good, experienced C++ programmers move to other companies and other operating systems!
END OF RANT.

@Fbody >>simply knowing that it's undefined should be enough.
I agree, but isn't it fun to speculate!

>>postfix versions have higher precedence than prefix version
Oh.. that destroys my explanation of that case that give 22.

Well better go to the source of Windows information. You should find what you want there.

well POSIX is not really for windows, I think there are some libraries to sort-of make it work, but Windows is not POSIX compliant (POSIX is essentially all operating systems except windows, see this wiki)

>>Well, if the sum of the length of two (hypothetical) sides is greater (or equal) than the other, it can't be a triangle.
I think you meant to say: "if the sum of the length of two sides is LESS (or equal) than the other, it can't be a triangle.

time.h does not support milliseconds, it is a C legacy library made for systems that "in general" cannot support more than seconds precision. Of course, modern computers do support milliseconds, and most often microseconds too. If your code is C, I believe there is no way. If in C++, there are OS specific calls (like posix time), but I recommend this Boost::date_time library, because it supports microseconds (or at least emulates it if the computer doesn't support it) and is not OS specific.

I guess this really is a case of undefined behaviour, because there is so much space for weird optimizations because of ambiguous operator priority... in any case, I think I cracked the last case giving 22. This is a pseudo-assembly code I can come up with to explain it:

// ((++j) + (++j)) + (j++) gives the following:
PUSH J,R1
COPY R1,R2
INC R1,1    //do first ++j
INC R1,1    //do second ++j
INC R1,1    //do j++
//now, R1 = 8, R2 = 5
COPY R1,RES //add ++j to result
ADD R1,RES  //add ++j to resul
ADD R2,RES  //add j++ to result
//now RES = 21

// j = ++j + ++j + j++; gives the following:
PUSH J,R1
INC R1,1    //do first ++j
INC R1,1    //do second ++j
//now, R1 = 7
COPY R1,R2  //copy initial value of j
//since initial value of j (R2) is equal to result of j++, the addition can be done now.
ADD R1,R1   //optimized addition of j = j + j to simply j += j
ADD R2,R1   //now add "initial value" of j.
//now R1 = 21 (3 x 7)
INC R1,1    //do j++
MOVE R1,J
//now J = 22

Wow! that's something creepy... trying this, it helps me understand why this is how it is:

int main(){

	{
        int j=5;
        std::cout << ((++j) + (++j)) + (j++) << std::endl;
        }
	{
        int j=5;
        std::cout << ((++j) + (++j)) << std::endl;
        }
        {
        int j=5;
        int x = ++j;
        x += ++j;
        x += j++;
        std::cout << x << std::endl;
        }
        {
        int j=5;
        j = ++j + ++j + j++;
        std::cout << j << std::endl;
        }
 
        return 0;
}

The output is:
21
14
20
22
At least on my computer.

I think the problem here is that the operator ++j will take the value of j after the whole expression evaluation. This explains the second case in my example, j is pushed, then incremented twice, then the values of both ++j terms are set to the value then (which will be 7), and are finally added. If you apply the same logic to the first case, the initial value of j is 5, so that is the return value of expression j++, then after two ++j and one j++, the final value of j is 8, so 8 + 8 + 5 = 21.

But the last case, I can't figure this one out, let me think about it a bit more. I think I will avoid using complex expressions with many ++ operators in the future, I guess that's what you should tell students too.

Don't let this blow your mind:

aReturnType some_function_name(aParameterType some_parameter, aReferencedType& some_ref_parameter) {
  aType some_variable(SOME_INITIAL_VALUE);
  for(anIterator some_iterator = some_start_value;some_iterator != some_end_value; ++some_iterator)
    some_variable += some_other_function_name(some_parameter, some_ref_parameter);
  return yet_another_function(some_variable);
};

These are just phony names people use in text books to make examples (so is Foo and Bar, before you ask).

is it compulsary to write main fun in c and c++,can we only write 1 main fun.

Well the main function is the entry point for the executable. Just a special function that the compiler knows should be the sort-of first implicit call to start the program. So if you are not making an executable, like making a DLL or library or something like that, then a main function is not necessary and probably will do more harm then good. If you have more than one main function, how is the compiler supposed to know which one is the "program function", which one to start at the start of the executable? So an executable requires one and only one main function, anywhere in the code (one exception: Win32 programs start with WinMain(), but still the same rule apply to winmain as for main). I'm not entirely sure, but I think that if you try to execute an executable with no main() function in the console, it will say "this program cannot be executed in console mode." and vice versa for winmain.

well i use bootime function to get and store time in my bios but i want to enter time in my system . what should i use for time and what to do for date well i am using time.h header files for that

I'm not sure I understand the goal, but you probably want to take a look at Boost::Date_Time library. This is cross-platform and …

Ok, now that I understand the problem, let me go through the problems with addNodeAtFront() function (see comments):

//First, this doesn't need to be a member function, see later for why that is.
template <typename T>
void node<T>::addNodeAtFront(const T& value, node<T> *frontNode){

	node<T> *newNode = new node<T>(value,frontNode);

	// Set the new node to point at the next node
        //--> This will introduce a cycle. Because most likely, in fact most certainly in a linked-list, frontNode will refer back to "this" node if you follow the next pointers, so setting the last node's next pointer to the front node will of course be a cycle.
        // As you said earlier, the next pointer has no reason to change.
	next = frontNode;

	// Set the new node to be the 'front'
        //--> I am surprised your compiler does not say "warning: this line ##: 'frontNode = newNode;' has no effect." (maybe a -Wall is missing or your compiler is stupid)
        // This has no effect because the frontNode pointer is passed by value and thus, changing it has no effect after returning from the function.
	frontNode = newNode;
}
//Since newNode is never "exported" outside the function, it is a memory leak. 
//It should be returned from this function as the new front pointer.
//Conclusion: this function does not need to exist, because the last two lines are useless, and the first line does everything you need. You can wrap it in this function if you want, for clarity, but it …

sorry,but I haven't got it.what do you mean by copying the data pointed to by d inside the Add function? do you know any other way for holding strings in linked lists?

I mean that the s.c_str() returns a pointer to the first character in the string. If later, you change or delete the string "s", the pointer you got from the previous call to c_str() is no longer pointing to the right place and the string that is "held" by your node will be lost or corrupted. This is why I say you should copy the data pointed to by d inside the Add function. What you need to do is inspect the size of the string, allocated enough memory for it, and copy the content of the string (the list of characters) to the new memory (I case you thought that was automatic, well it's NOT). This way your node is holding it's OWN copy of the string and there is no danger that another part of the software might temper with it, this is part of the idea of encapsulation.

At no time has floats ever been faster than doubles.

Well... that's absolutely true, if you restrict the discussion to the CPU. But floats have always been very popular for efficiency reasons in game programming because GPUs are (or at least "were", in my days) designed with custom floats (often 5 bytes for 4d vectors of 20 bytes in total). So, since conversion is inevitable and precision is of very little concern, floats being smaller means faster transfer rate from the main computer to the graphics card, which was one of the big bottlenecks in the rendering loop (since not enough memory was available on the graphics card to hold all the game data, there was a lot of memory-transfers). So a slightly higher cost of each FPO for the relatively small amount of operations done the CPU was a fair price to pay for increased throughput to the GPU.

p->next will be NULL for sure, do you see any line in addNodeAtFront() which starts with "next =".. the answer is no. So next will start with the value NULL and will remain that way.

I think you have mixed up front and next in your addNodeAtFront().. not entirely, but enough that I can't understand where the new node that is added should stand, and what exactly front and next point to, in the whole scheme of things.

Think of a linked list as a chain (excuse the ascii artwork, and I will use prev for what I think you call front):

NULL
 ||
prev <- node1 -> next
          ||      ||
         prev <- node2 -> next
                           ||
                          NULL

So to insert a node between node1 and node2 from the above, you need to set the new_node->prev to node1, node1->next to new_node, new_node->next to node2 and node2->prev to new_node. All these are accessible from either node1 or node2 (hence, a bi-directional linked-list). If you are implementing a unidirectional linked-list, then it is the same business but simpler, and of course, you can only add elements in one direction.

But again, I'm not sure of what you want to accomplish, what does length really mean in a linked-list? The idea of a linked-list is that it is decentralized, i.e. you shouldn't need any oversight as to the length, to go through the list in one direction, you start at the first node and follow the next pointers until …

1.
For C++, I would disagree with case 1 above, in this case you want to use a reference as in:

#include <iostream> //notice no .h here
void change(int a) {
	a+=1;
}
void changeref(int& a) { //notice & instead of *
	a+=1; //notice no leading *
}
int main() { //notice standard is int return for main()
int a=0;
change(a);
cout<<"a="<<a<<endl;//see how the value didn't change
changeref(a); //notice "a" directly
cout<<"a="<<a<<endl;//see how the value  changed because we are dealing with a reference
}

2.
I agree that probably the main purpose for pointers is for dynamic allocation of memory (new & delete). However, in modern C++, especially with the new extension TR1, a much safer practice is to use smart pointers (especially the duo shared_ptr and weak_ptr).

So most of the time, references are better suited, and their main difference to pointers is that they cannot be "re-seated" in the sense that once a reference refers to some variable it can never be made to refer to something else, and they cannot refer to nothing (this is what makes them safer, but also makes (smart) pointers the only candidate for dynamic memory allocation). But now, considering smart pointers, many people now call pointers like "char*" or "int*" or whatever as C-style pointers because their role has been pushed to the realm C legacy code.

One useful purpose of (smart) pointers is to modify a unique object somewhere, like in case 1 above, but where …

Are you trying to write a SpyBot? I'm not going to be the one to help you with that... are you also trying to read the credit card numbers that people might be writing on other open windows, while they are "playing your game"... just joking!

To be fair, I will presume your innocence before proof of guilt... so to answer the question, I don't think that this is possible within normal channels (i.e. without some dirty hacks) for obvious security reasons. And I can't remember ever seeing a software do that except viruses or other undesirables, anti-viruses don't even do that! At least, as far as I know, and I hope I'm right! The IT world is no place for Big Brother.

It seems quite alright to me! One tip:

//THIS:
cin>>userIn;//get user input

int loopLimit = atoi(userIn.c_str());//get the numberEntered

//COULD BE JUST THIS:
int loopLimit;
cin>>loopLimit;//get user input

SORRY! to Kanoisa and Fbody..

I want to post this RETRACTION to my comment on delete being OK in this case. It is not! I was wrong and I am sorry for it. Please read this for details. I guess you learn new things everyday.. even after several years of programming...(it has also been a while since I used C-style arrays)

@Kanoisa (saransh, please ignore):
>> //this shouldent work it should be delete [] ptr.
For primitive types like char, it works fine. When dealing with objects with non-trivial destructors, if delete[] is not called it will not call the individual destructor of each element, but the overall memory is still deleted fine (it's because the heap is made to deallocate memory blocks based only on the starting pointer and will deallocate the whole block whether delete or delete[] is called). Of course, it's a good habit to use delete[] everywhere, but not strictly required for POD types. So the behaviour of "cout<<endl<<ptr;" is expected to be like saransh reports it to be whether "delete" or "delete[]" is used.

Well in "char* str="my name";" the _string_ "my name" is a list (or array) of characters (char) and "str" is a pointer to the first character in the list. So by incrementing the pointer "str" you get a pointer to the next character, then the next, and the next again, until you hit a character which is 0 (or '\0'), hence the name "null-terminated string". This is what "strlen(str)" does, it goes from character to character, starting from the pointer "str" to find the null character, and then it returns the count of how many characters there are before the null character (which terminates the string).

>>/*is this ptr pointer or string*/
Well as in the above, a pointer to chars (char*) is a pointer. If there is a null-character at the end, which it will after the call to "strcpy", it can be called a string, or null-terminated string.

>>/*this 'ptr' should be destroyed as effect of "delete ptr",but still displaying here when executed*/
Well, when you call "delete" it simply deallocates the memory pointed to by "ptr". This means that the program will consider that memory free to use for another memory allocation (like a call to "new"), but it doesn't replace the memory with anything, it simply marks it a free or available. When calling "delete", the pointer "ptr" is not changed in value, it still points to this address in memory, which still has the same null-terminated string saved there. That is …

Simplest program, the famous Hello World program:

#include <iostream>

int main() {
  std::cout << "Hello World!" << std::endl;
  return 0;
};

There is one naming convention that is used a bit and it's called Hungarian notation. I'm not sure of the exact format, but essentially it uses leading letters to indicates certain things, more or less like this:

class IAbstractClass { //notice "I" for abstract or interface or base classes.
  public:
    virtual void SomeMethod() = 0; //notice camel-back writing.
};
class CConcreteClass : public IAbstractClass { //notice "C" for class or concrete class.
  private:
    int mIntegerDataMember; //notice "m" for member, as in data member.
    IAbstractClass* pSomePointer; //notice "p" for pointer data member.
    IAbstractClass& rSomeRef; //notice "r" for some reference.
  public:
    void SomeMethod(); 
};

But this is an old naming convention that is now regarded as a bit retarded. Personally, I like the naming convention from the Boost libraries and the STD/STL libraries, but I used to loosely follow Hungarian notation so a lot of my code is a bit of a mix. What I try to follow now is more a _ separated words for classes, structs and other type names, and camel-back for data members and methods with first lower-case letter (or sometimes I use _ separated the data members too!), something like this:

class abstract_class { //notice all lower-case and _ separated.
  public:
    virtual void someMethod() = 0; //notice camel-back with lower-case start.
};
class concrete_class : public abstract_class { //notice no difference for concrete classes.
  private:
    int IntegerDataMember; //notice camel-back data member.
    abstract_class* SomePointer; //notice camel-back data member.
    abstract_class& SomeRef; //notice camel-back.
  public:
    void someMethod(); 
};

First off, I can't help on the AT side, but I know matlab pretty well. There are essentially two possibilities: either run in matlab and use DLLs to interface to C++ code to deal with AT commands and whatever else, or compile matlab using RTLab. So if you are in matlab, you can wrap all you C++ code inside some dynamic link libraries (DLL) and call them from matlab (all I know how to do is from SimuLink with SFunctions). Otherwise, you need the package RTLab in matlab which allows you to compile the matlab code into a DLL and then call it from your C++ code. One way or the other is a bit of work.

So third option, if all you need to do is some image processing in matlab, why don't you use the library OpenCV (Open-source Computer Vision libraries)? They have all image processing, stereo vision, matching, filtering, etc. etc. functions built-in as c++ code, so that would solve the problem. I know people who use this library and apparently it is very good!

Generally speaking, interfacing matlab and C++ is rarely worth the trouble because most matlab code can be translated into C++ quite easily, and it executes much faster.

Yes and no. This will create a different static variable in each .c you compile. To solve this, declare it as "extern" as well, this will tell the compiler to look for all other declarations of the same variable and "merge" them into a single one. Of course, if having a different static variable in each .c you compile is what you are looking to do, them it's fine.. as far as I know, but I never use global variables anyways, it's not recommended to do so, look at this.

Well I don't know what you imagine "x^y" to be supposed to do, but I can tell you what it does and why the compiler warns you about it. The ^ operator in C++ is a bitwise XOR operator, so x^y produces the results of x XOR y (XOR is btw the exclusive OR operator, remember those lame binary number exercises from computer science 101..). So the compiler complains because you evaluate an expression and don't store it anywhere, and thus, it "has no effect".

Google for the "bit shift operators in C++", it's the key to solving this problem.

EDIT: beat me at it jonsca!

Well your code is definitely not the problem, it is how you put it together.

Do you have "#include "HW8P1Class.hpp"" at the start of the "HW8P1Main.cpp" file?

And do you add the "HW8P1Class.cpp" to be built along with "HW8P1Main.cpp"?

I can guarantee that if you do this right, it will compiler fine... well unless you have other errors after..

Well I don't know what weird thing is going on on your side, but copy/paste this:

#include <iostream>
#include <cmath>

using namespace std;

float sin_taylor(float x) 
{ 
        float result = x;
        float term = x;    // ADD THIS
 
        int limit = 30; 
        int sign = -1; 
 
        for(int i=3 ; i<limit ; i+=2,sign=-sign) {
                term = -term*x*x/(i*(i-1)); //
                result += term;                 //make this change
        };
 
        return result; 
}

int main() {

  int i = 0;
  float sum = 0.0;
  for(float x=0;x<6.28;x+=0.01, ++i) {
    sum += fabs(sin(x) - sin_taylor(x));
  };

  sum /= i;

  cout << "Average error is: " << sum << endl;

  cout << "sin( 2.3145 ) = " << sin_taylor(2.3145) << endl;

  return 0;
};

If the result in the console is not the following, then call an exorcist!
Average error is: 3.11248e-07
sin( 2.3145 ) = 0.735966

You will also see inline class methods used extensiely in the STL header files such as <string>, <vector>, <list>, <fstream> etc. I believe the reason is because they are templates.

That's right! When it comes to templates, it's a whole bunch of additional issues with respect to code in header or cpp files. Look up "template instantiation", or read this.

well front() maybe.. whatever, I don't understand the purpose of the AddElement function so I don't know how exactly you want to call it. What I do know is that "pipes" is of type "list<clsMyClass>" and that AddElement is a member of clsMyClass, and thus you need to get a clsMyClass object to call AddElement, so "pipes.AddElement(..)" will not compile for sure, but "pipes.back().AddElement(..)" will compile. Whether it does what you want or not I don't know, I am not inside your brain, I can't understand the mean if I don't know the end.

Increase the variable "limit" to 30 or 40 or 100 and see what happens.

Well for small projects it ok to put everything in the header files, but as the project grows it will become more and more inconvenient. Since you have read stuff on C++ I will not repeat to much that the "philosophy" behind headers and cpps is to declare classes and functions in the header and implement (or define) them in the cpp.

In practice, when you compile a C++ project, you typically compile a bunch of cpp files together in an executable, an object file (.o), a static library (.a or .lib) or a shared library (.so or .dll). These contain the executable code, already compiled. So in the case of object files and static libraries, they contain the compiled version of your implementation (in the cpp files) and what they contain is declared in all the header files relevant to which cpp files you compiled into these object files and static libraries.

So.. what difference does it make to put code in cpp or header? Well header files are included all the time by other headers, other libraries, other parts of your project in general (think of it as other packages, in Java). So the more code you put in the header files the more stuff you require the compiler to compile for every individual part of project you are compiling. This will increase code size, and worse, increase compilation times (and it will get very annoying, very quickly!). Putting code in C++ files and nothing but …

Look up SDL (cross-platform API like the Win32 API) or Qt (like MFC or other GUI libraries).

Well this is possible:

class clsMyClass {
	private:
		unsigned int id, nodStart, nodStop;
		float pipeLen, pipeDiam;
	public:
		void AddElement(clsMyClass element, list<clsMyClass>& elements);
};

//.. in cpp
void clsMyClass::AddElement(clsMyClass element, list<clsMyClass> &elements)
{
        //.. do whatever extra thing you like here.
	elements.push_back(element);
        //.. or here.
}

//main.cpp:

int main() {
  //...
  list <clsMyClass> pipes;
  //...
  pipes.back().AddElement(element,pipes); //see here you have to access back() to call AddElement.
  //watch out that back may not exist if list is empty.
  //...
};

But I would not recommend doing this, it is bad design, too convoluted. Implement your own list class. And if at the lines where I wrote "do whatever extra thing you like here... or here.", you have nothing more to put, then just use list the conventional way:

class clsMyClass {
	private:
		unsigned int id, nodStart, nodStop;
		float pipeLen, pipeDiam;
        public: 
                //.. public interface..
};

//main.cpp:

int main() {
  //...
  list <clsMyClass> pipes;
  pipes.push_back(element); 
  //...
};

Well it looks like a good book, and gamedev is a good source for openGL game programming. Consider first going through the NeHe Tutorials, that's a great start for openGL rendering (but the advanced tutorials are a bit outdated, in the sense that better techniques exist today).

About the book being outdated, well openGL is fully backward compatible, so anything that was working before, still works now on newer hardware. The problem is that when you reach roughly the second half of that book (from looking at the chapter lists) there will be things for which there are better techniques today (like pixel-shaders, render-to-texture, etc.).

So for a starter, I would suggest you go through the NeHe tutorials for all the basics, get to know the OpenGL Red Book and Blue Book (and the rest of the documentation at opengl.org). Then get a newer book for openGL that includes more recent things (especially pixel-shaders, now-a-days, don't get a book that doesn't talk about those, same goes for render-to-texture). This is because if the book doesn't cover all the newest things, only the basics are relevant, and I can tell you that you will go through the basics pretty quickly and then the book will be useless.

I may have missed something important in the newer important features, because I am, myself, a bit outdated on opengl stuff. But understand that all the basics are the same, opengl is incremental, first make a window, …

Well you can always implement your own linked-list to have all the custom behavior you want. Standard containers like list are "general purpose" meaning they are usually sufficient for most applications, but you can always make your own, but it's a bit more work... or more fun, depending on how you look at it ;) .

So if I understand right, you want to do something extra when an element is added to the list (more than just creating the new object and inserting it). Then, you can make a class that contains the list of classes (objects btw) and define your own methods to push, pop, insert, iterate, etc. where you do whatever extra thing you need to do. The point is, that cannot be done within the objects that are held as elements of list.

If you really want to not have a class that manages the list, you can look at what is possible by implementing your own "allocator" (which is the second, "hidden" template parameter to list), but the capabilities are a bit limited, you still won't be able to access the list itself, only the one element you are inserting.

Why do you need AddElement? the list already has functions to add (push_back), delete, insert, etc. All you need to take care of with the clsMyClass is make sure that all constructors work (and do not throw exceptions) and that you have proper copy-semantics, i.e., you need to implement a copy-constructor and assignment-operator if the default copy-semantics are not valid for your case. That's all, enjoy.

To match your very little effort at asking the question..
my answer is: std::sort (<algorithm> header).

Congrats!

When it comes to the initial errorneous code, you can post as much as you want to help us find the errors (as long as it is not way too big). Because if someone else comes and copy/paste it for his own assignment, he will get the bad grade he deserves.

C++ is the most flexible and universal language for programming. Look at the list firstPerson posted. It goes to show that virtually all games are in C++, virtually all serious scientific coding is in C++, all Microsoft apps too, virtually all kernel libraries of operating systems, etc. etc.

One of the reason for this, in my opinion, is that if you ask an experienced programmer about what language should be used for a particular project, it's almost certain he will say C++ even if he knows many others that would do the job. While some languages are better suited for certain applications, C++ is BEST suited for everything. So whenever these companies start a project, they hire some really good programmers and those programmers tell them to make their app in C++, because it's the most flexible and productive language out there, and it is guaranteed to last. I personally don't know a single experienced programmer that is not primarily a C++ programmer, that means, if he can choose he will program in C++, if he doesn't have a choice, e.g., joins a project that already uses another language, then he can program in that language without any problems (partly due to the fact that if you are very good at C++, you're good at any other language, and employers know that!).

If I run the code that I have posted (which is correct, for sure!) I get the following:

Average error is: 0.038862 for limit = 15;
Average error is: 3.11248e-07 for limit = 30;

This was by calculating at every 0.01 rad increment between 0 and 2pi. This is totally as expected. Taylor series calculation is approximate! So expect some error.

One note on this, the Taylor series expansion is only good around a value of 0 rad (up to and beyond 2pi), but don't try to calculate the sin or cos on a really large value, keep it within the -2pi to 2pi range (you can even add a check at the start of your function to make sure the input is in the -pi to pi range).

Try to write a serialization library like this one. That should keep you busy for a while, and help you learn advanced OOP concepts of C++ that may challenge you a bit. Also see these tutorials, they will show many nice ways of mixing template meta-programming and generic programming, that you don't find as much in other languages.

But again, it's hard to tell how "experienced" you are, but you sure solved firstPerson's problem quickly.

You should copy the data pointed to by d inside the Add function, because of this, from www.cplusplus.com on string.c_str():

The returned array points to an internal location with the required storage space for this sequence of characters plus its terminating null-character, but the values in this array should not be modified in the program and are only granted to remain unchanged until the next call to a non-constant member function of the string object.

I don't know if it's what causes the error, but try it out, it is better anyway.