Hopefully novice code question.

Hello everyone! This will be my first time posting, but not my first time acquiring knowledge from this veritable cornucopia. I do hope that I am properly following all of the guidelines, and that my question isn't too vague.

Essentially I had a homework assignment where I needed to do a number of things to an array of objects. They were of two classes, student():person(), and faculty();person() that were both under an array called pPoint[50], where the students had 0-24, and the faculty had 25-49. I was able to get the program working on all fronts, aside from a sorting function.

I slaved away at the function, thinking that I had everything syntactically correct. Every time that I access this part of the program however, my debugger goes bananas (Visual Studio 2010). Every time I get to this section, it gives me the following, "Unhandled exception at 0x00e63b66 in Homework4.exe: 0xC0000005: Access violation reading location 0xcccccd04."

Is there something incorrect that I have done here? Side note, if more code is needed, please let me know. I just didn't want to flood the page with the program.

Thank you to all who read this posting.
-Me

Code:

---

for (sortA = 0; sortA < 23; sortA++)
                                {
                                        for (sortB = 0; sortB < 23; sortB++)
                                        {
                                                if (pPoint[sortB]->getName() > pPoint[sortB+1]->getName())
                                                {
                                                        sortC = pPoint[sortB+1]->getName();
                                                        pPoint[sortB+1]->setName(pPoint[sortB]->getName());
                                                        pPoint[sortB]->setName(sortC);
                                                }
                                        }
                                }

---

Please post your class definition for your pPoint variable, and show how your declared pPoint.

Jim

If 23 is the maximum size of your array pPoint, it should definitley crash while execution but as jimblumberg said, post your code here so that we could have a look over the variables declarations and initiliazations...
Regards...

Here is the lot of it.

Some of the code is a little asinine, but it was for a class project, so the instructor just needed to see that we knew our syntax, etc. The program has been turned in, I was mostly just bothered by that one part not working properly.

Code:

---

//Use one array of type Person

#include <iostream>
#include <string>

using namespace std;

class Person
{
private:
        string id;
        string name;
        string address;
       

public:
        void setId(string i) {id = i;}
        void setName(string n) {name = n;}
        void setAdd(string a) {address = a;}

        string getId() {return id;}
        string getName() {return name;}
        string getAdd() {return address;}

        Person() {setName(" "); setId(" "); setAdd(" ");}
        Person(string i, string n, string a){setName(n); setId(i); setAdd(a);}
       
        virtual void print() {cout << endl << "Name: " << name << " ID: " << id << " Address: " << address << endl;}
};

class Student : public Person
{
private:
        double gpa;
        string status;

public:
        void setGpa(double g) {gpa = g;}
        void setStatus(string s) {status = s;}

        double getGpa() {return gpa;}
        string getStatus() {return status;}

        Student():Person()
        {
                gpa = 0.0;
                status = " ";
        }

        Student (double g, string s, string i, string n, string a):Person(i, n, a)
        {
                gpa = g;
                status = s;
        }
       
        void print() {cout << endl << "Name: " << Person::getName() << " ID: " << Person::getId() << " Address: "
                              << Person::getAdd() << " GPA: " << gpa << " Graduate Status: " << status << endl;}
};

class Faculty : public Person
{
private:
        string department;
        string rank;

public:
        void setDepartment(string d) {department = d;}
        void setRank(string r) {rank = r;}

        string getDepartment() {return department;}
        string getRank() {return rank;}

        Faculty():Person()
        {
                department = " ";
                rank = " ";
        }

        Faculty (string d, string r, string i, string n, string a):Person(i,n,a)
        {
                department = d;
                rank = r;
        }
       
        void print() {cout << endl << "Name: " << Person::getName() << " ID: " << Person::getId() << " Address: "
                                          << Person::getAdd() << " Department: " << department << " Rank: " << rank << endl;}
};

int menuThing(int z);

int main()
{
        int exitParam = 0;
        int choice;
        int sCounter = 0;
        int fCounter = 25;

        int sortA = 0;
        int sortB = 0;
       
        string tempid = " ";
        string tempname = " ";
        string tempadd = " ";
        string sortC = " ";

        Person *pPoint[50];
       
       

        while (exitParam == 0)
        {
                cout << endl << "1-For Student" << endl << "2-For Faculty" << endl << "3-Exit" << endl << ">>> ";
                cin >> choice;

                if (choice == 1)
                        switch (menuThing(1))
                {
                        case 1:
                                system("cls");

                                if (sCounter > 24)
                                {
                                        cout << endl << "No more room for Students!" << endl;
                                        break;
                                }

                                cout << "\t\tAdd a student." << endl;
                                pPoint[sCounter] = new Student();

                                cout << "Enter id: ";
                                //cin >> tempid;
                                fflush(stdin);
                                getline(cin, tempid);
                                pPoint[sCounter]->setId(tempid);
                                cout << endl << "Enter full name : ";
                                fflush(stdin);
                                getline(cin, tempname);
                                pPoint[sCounter]->setName(tempname);
                                cout << endl << "Enter Address: ";
                                fflush(stdin);
                                getline(cin, tempadd);
                                pPoint[sCounter]->setAdd(tempadd);
                                cout << endl << endl << "Student added!" << endl;
                               
                                if (sCounter < 25)
                                        sCounter++;
                                if (sCounter > 24)
                                        cout << endl << "No more room for Students!" << endl;
                                break;
                        case 2:
                                break;
                        case 3:
                                break;
                        case 4:
                                for (sortA = 0; sortA < 23; sortA++)
                                {
                                        for (sortB = 0; sortB < 23; sortB++)
                                        {
                                                if (pPoint[sortB]->getName() > pPoint[sortB+1]->getName())
                                                {
                                                        sortC = pPoint[sortB+1]->getName();
                                                        pPoint[sortB+1]->setName(pPoint[sortB]->getName());
                                                        pPoint[sortB]->setName(sortC);
                                                }
                                        }
                                }
                                break;
                        case 5:
                                break;
                        default:
                                cout << endl << "Invalid selection." << endl;
                                break;
                }
                if (choice == 2)
                        switch (menuThing(2))
                {
                        case 1:
                                break;
                        case 2:
                                break;
                        case 3:
                                break;
                        case 4:
                                break;
                        case 5:
                                break;
                        default:
                                cout << endl << "Invalid selection." << endl;
                                break;
                }
                if (choice == 3)
                        exitParam = 1;
        }
       
       
       
       
       
       
       
       
       
       
       
       
        system("pause");
        return 0;
}



int menuThing(int z)
{
        int selection = 0;
        if (z == 1)
        {
                system("cls");
                cout << endl << "1) Add a new student" << endl;
                cout << "2) Print the information for a student" << endl;
                cout << "3) Delete a student" << endl;
                cout << "4) Sort students by name" << endl;
                cout << "5) Quit" << endl;
                cout << "Enter your selection : ";
                cin >> selection;
        }

        if (z == 2)
        {
                system("cls");
                cout << endl << "1) Add a new faculty" << endl;
                cout << "2) Print the information for a faculty" << endl;
                cout << "3) Delete a faculty" << endl;
                cout << "4) Sort faculty by name" << endl;
                cout << "5) Quit" << endl;
                cout << "Enter your selection : ";
                cin >> selection;
        }

        return selection;
}

---

I first enter 1 and then 4.
Now check your pointer condition....
Your pointer is not pointing to any where, means it's a dangling pointer.
Now, start handling it...
Good luck

A couple of things. First off, is it really necessary to use new here? If it is, then you are not freeing everything. Either use delete or use a smart pointer (see SourceForge.net: Raw pointer issues - cpwiki).
Secondly, fflush(stdin) is undefined. Don't use it. Ever. SourceForge.net: Fflush - cpwiki. Also, do not mix C and C++-style I/O. The result is, again, undefined. fflush is C. getline is C++.
Also consider that your sort function will sort all objects. But what happens if you have less than 50 objects? You will have pointers pointing to neverland!

As far as necessary, it was what our instructor wanted us to do. He's had us do a ton of things that were essentially nonsense, just to try to demonstrate that we understand syntax.

I tried it using sCounter-1 in the sorting for loops, and it didn't give me the error.

I think I understand what you are saying in that it is trying to access a piece of data that doesn't exist.

In regards to not using fflush, what alternative is there?

Also, I have done some searches, and there is so much information, and so many books out there, it's hard for someone like myself to know where even to start. Being a novice, when I pull up some of the pages that I am referenced to, they are full of information that I just don't understand yet. It can occasionally be frustrating, but it's still a tremendously fun hobby.

Best way:

#include <limits>
std::cin.ignore(std::numerical_limits<int>::max()) ;

Or if you can't memorize that, just

std::cin.ignore(n);

Where n is a sufficiently large n to clear out anything left in the input buffer, say, 1000 or so.

Quote:

---

see SourceForge.net: Raw pointer issues - cpwiki

---

Take this with a grain of salt: it's more like Elysia's personal take on the subject. This article isn't even linked anywhere else in the rest of the encyclopedia. And no one besides him edits the pages anymore.

Oh indeed? To me, it clearly points out some issues with raw pointers and solutions to those problems.
Or rather I should say, instead of criticizing the article, help out by fixing it or pointing out its flaws instead of steering people away from resources.

Quote:

---

it clearly points out some issues with raw pointers and solutions to those problems.

---

Even if I agreed, it's still largely your opinion on the subject. Take this:

Quote:

---

What happens, if somewhere inside the function, something throws an exception? Considering that we've allocated some memory with new, we must delete that, but if an exception is thrown, then the execution of the code will follow on the nearest catch block. So that means, that to ensure we do not leak memory, we have to make a local catch block, try to free all the memory allocated, then re-throw the exception.
This happens since raw pointers are not automatically freed, and thus can be quite cumbersome.

An example of how to do this is not offered, since it is not considered a good solution.
However, a curious reader may wonder. Clearly, we can associate this problem with many other things, such as writing some information to a file, or some like. Some operation that, if the function fails, must be rolled back. That is, undone. Surely smart pointers cannot be used for all these things? Well, yes and no. While smart pointers are indeed powerful, they cannot do everything. Discussion of exception safety is a topic of its own and is not the scope of this article. Instead, a curious reader is directed to reading about Boost.ScopeExit.

---

How is that not entirely your opinion on what a good solution is? I mean, you mention that you can catch an exception in the constructor and then rethrow the exception after deleting, but it's not considered a good solution and is quite cumbersome. No one necessarily knows why, and even if we did that's your opinion.

Recommending smart pointers is OK, but I don't see them using a different technique to make their code exception safe. Much better articles are abound, such as this one: pointers.

The other part of it is literally just about how delete is easy to forget and how smart pointers are just better, which I don't find to be educational.

The ticking time bomb solution code still has syntax errors. return; instead of return *this;

Since no one edits the pages anymore, I'd rather see that site become obscure. But I think largely what you have to say here needs to be integrated into the pointers page.

Quote:

---

Originally Posted by whiteflags

How is that not entirely your opinion on what a good solution is? I mean, you mention that you can catch an exception in the constructor and then rethrow the exception after deleting, but it's not considered a good solution and is quite cumbersome. No one necessarily knows why, and even if we did that's your opinion.

---

No, I think that is quite widely accepted, and shared among many as a good solution, because catching and rethrowing exceptions is just not something I see recommended. The recommended solution is use RAII, and that is exactly what smart pointers do.

Quote:

---

Recommending smart pointers is OK, but I don't see them using a different technique to make their code exception safe. Much better articles are abound, such as this one: pointers.

---

Changing their code to make it exception safe? Probably not. But it is valuable knowledge for future projects. Exceptions are a big part of C++, and smart pointers play a huge role in making exception safe code, and that is mostly what the article wants to bring forth.
Is the wording wrong? Perhaps. These things are all too subjective.

Quote:

---

The other part of it is literally just about how delete is easy to forget and how smart pointers are just better, which I don't find to be educational.

---

For newbies, I find it very educational since a lot of newbies don't even call delete in the first place.

Quote:

---

Since no one edits the pages anymore, I'd rather see that site become obscure. But I think largely what you have to say here needs to be integrated into the pointers page.

---

So where do you put up FAQs and articles on subjects, then? The board? The FAQ board which isn't used? The FAQ page on the site which pretty much isn't used?
The point is, the site is a place to store such articles so that we don't have to repeat things. And frankly, lengthy explanations do not tend to be incorporated into replies. That means newbies get less useful information rather than if there was a site where articles were written full of good information.

But even for all this debate, I still fail to see why it would be bad to refer people to that article. It may not be perfect. It is not meant to be perfect. It is meant to be usable.

Quote:

---

Originally Posted by Elysia

Oh indeed? To me, it clearly points out some issues with raw pointers and solutions to those problems.
Or rather I should say, instead of criticizing the article, help out by fixing it or pointing out its flaws instead of steering people away from resources.

---

I am inclined to agree with elysia on this one. raw pointers are almost completely obsolete in C++. there are very few cases where you MUST use a raw pointer. nearly everything can (and should) be done with the appropriate facility in the C++ standard library - string, vector, auto_ptr/shared_ptr, etc. in todays environment of malware, safety and security are EVERYTHING. pointers provide absolutely no safety. in my own code, I try to use references whenever it is possible, using pointers only when I need to dynamically create something that needs to persist outside the scope in which it was created.

Quote:

---

Originally Posted by Elysia

No, I think that is quite widely accepted, and shared among many as a good solution, because catching and rethrowing exceptions is just not something I see recommended. The recommended solution is use RAII, and that is exactly what smart pointers do.

---

If the recommended solution is to use RAII, and catching exceptions from a constructor, cleaning up after the constructor, and rethrowing the exception follows RAII, then why is it not recommended? Is that not entirely your opinion?

Quote:

---

Changing their code to make it exception safe? Probably not. But it is valuable knowledge for future projects. Exceptions are a big part of C++, and smart pointers play a huge role in making exception safe code, and that is mostly what the article wants to bring forth.
Is the wording wrong? Perhaps. These things are all too subjective.

---

I meant that shared pointer implementations also throw exceptions from constructors and call delete p before reraising it. So, since it is a used solution and you're going to mention it, I don't see how it's correct to say it's not recommended. Even if it's not recommended, it's in your opinion only.

Quote:

---

So where do you put up FAQs and articles on subjects, then? The board? The FAQ board which isn't used? The FAQ page on the site which pretty much isn't used?

---

Who said it wasn't used? People link to it all the time on here.

Quote:

---

But even for all this debate, I still fail to see why it would be bad to refer people to that article. If may not be perfect. It is not meant to be perfect. It is meant to be usable.

---

I don't think an article that's largely someone's unsupported dubious opinions is useable, or I wouldn't have brought it up.

Quote:

---

Originally Posted by whiteflags

I don't think an article that's largely someone's unsupported dubious opinions is useable, or I wouldn't have brought it up.

---

Well, it might be usable, but not present a complete picture. That said, I don't think the code for "write a custom copy constructor and assignment operator that makes a copy of the raw pointer and does not merely copy over the raw pointer's value" is usable: it is not exception safe and does unnecessary work.

It is not exception safe because delete m_int in the copy assignment operator is used before m_int = new int. Since new int could throw std::bad_alloc, it should be done first, i.e., using another variable that is then assigned to m_int after the delete. But I say that this is unnecessary work because there was no need to use delete in the first place (but then there was no need to use a pointer in the first place, so perhaps this is not a valid objection).

Furthermore, unlike the copy and swap idiom, the use of the copy assignment operator to implement the copy constructor is not a normal idiom, in my opinion. Given that the use of a pointer is contrived to demonstrate new and delete, I might have written:

Code:

---

A(const A& rhs) : m_int(new int(*rhs.m_int)) {}

A& operator = (const A& rhs)
{
    if (&rhs != this)
    {
        int* temp = new int(*rhs.m_int);
        delete m_int;
        m_int = temp;
    }
    return *this;
}

---

Quote:

---

Originally Posted by whiteflags

If the recommended solution is to use RAII, and catching exceptions from a constructor, cleaning up after the constructor, and rethrowing the exception follows RAII, then why is it not recommended? Is that not entirely your opinion?

---

That is not the point. The constructor must clean up after itself, so why should the constructor be an exception to the RAII rule? If the code that uses the class uses raw pointers, and therefore makes it safe by wrapping them in smart pointers, then why should not a constructor do so?
The constructor should not clean up by catching the exceptions and re-throwing them. It should rely on objects destructors--objects used inside the constructor--to clean up. That makes the constructor safe, and thus the class safe.
Catching exceptions to clean up is cumbersome and dangerous--it can lead to many bugs. Plus it's expensive to rethrow an exception.
It is like building blocks. Always use building blocks that clean up after themselves everywhere. A raw pointer does not clean up after itself, therefore it is dangerous. A smart pointer will always clean up if properly used, and is therefore safe to use. Even in constructors where you won't have to catch the exception to clean up by using them.

Quote:

---

I meant that shared pointer implementations also throw exceptions from constructors and call delete p before reraising it. So, since it is a used solution and you're going to mention it, I don't see how it's correct to say it's not recommended. Even if it's not recommended, it's in your opinion only.

---

What would such a scenario be? I cannot think of such a scenario where a smart pointer would catch an exception only to delete its raw pointer. That would be silly, since the destructor would always take care of that.
And no, it's still not my opinion. Catching and rethrowing exceptions is cumbersome and expensive, and is therefore generally not recommended when there are alternative solutions available. And in 99% of the cases, there are.

Quote:

---

Who said it wasn't used? People link to it all the time on here.

---

Linked to is not the same as new articles created there, which is what I was referring to.

Quote:

---

What would such a scenario be? I cannot think of such a scenario where a smart pointer would catch an exception only to delete its raw pointer. That would be silly, since the destructor would always take care of that.

---

If you throw an exception from the constructor, the class destructor will never be called. Only the destructors of member objects. And the raw pointer that a smart pointer does contain has a useless destructor.

Quote:

---

And no, it's still not my opinion. Catching and rethrowing exceptions is cumbersome and expensive, and is therefore generally not recommended when there are alternative solutions available. And in 99% of the cases, there are

---

Perhaps I should be more stern: I don't care what's recommended, and it has to be damned wrong to say something isn't if that's the only thing people do in such a situation, no matter if its hidden away in a proper solution.

Quote:

---

Linked to is not the same as new articles created there, which is what I was referring to.

---

Be the change that you want to see in the world. It's probably a good idea to be in the right when you do, though.

Quote:

---

Originally Posted by whiteflags

If you throw an exception from the constructor, the class destructor will never be called. Only the destructors of member objects. And the raw pointer that a smart pointer does contain has a useless destructor.

---

If you do anything that might throw an exception inside a smart pointer, then you would wrap your raw pointer in another smart pointer, such as std::unique_ptr. Thus, you do not need to catch the exceptions.

Quote:

---

Perhaps I should be more stern: I don't care what's recommended, and it has to be damned wrong to say something isn't if that's the only thing people do in such a situation, no matter if its hidden away in a proper solution.

---

...And it very likely isn't even used in such a situation. The proper solution is... yes, you guessed it, again, to use proper RAII techniques. Wrap all resources into containers and use Boost.ScopeExit to take care of cleaning up that needs to be done when the function exits.
It isn't a widely used practice at all, to catch and rethrow exception to my knowledge.
And even if it is, it's not a thing I would recommend--or teach--newbies.
Even if it is just my opinion, it's not a bad opinion, and therefore I see no problem in letting people know about it. Everyone voices their opinions all the time. And this opinion is not bad practice.

Quote:

---

Be the change that you want to see in the world. It's probably a good idea to be in the right when you do, though.

---

What is right to me is not necessarily right to you. You cannot expect everything written by me--or anyone else--to be free of criticism.

Quote:

---

...And it very likely isn't even used in such a situation. The proper solution is... yes, you guessed it, again, to use proper RAII techniques. Wrap all resources into containers and use Boost.ScopeExit to take care of cleaning up that needs to be done when the function exits.
It isn't a widely used practice at all, to catch and rethrow exception to my knowledge.

---

Well it must be. I'm insisting that smart pointers themselves, in their simplest implementation, use the very technique you denounce to make their code exception safe. Boost is one example. Only the default constructors do not throw.

I don't see the point in your insistence that its bad to teach a working, RAII following, standards reliant solution that could very well be used, and to my knowledge is used, at some level in so called safer things, in addition to the other crap you could use.

Quote:

---

Originally Posted by whiteflags

Well it must be. I'm insisting that smart pointers themselves, in their simplest implementation, use the very technique you denounce to make their code exception safe. Boost is one example. Only the default constructors do not throw.

---

Smart pointers in their simplest implementation most likely do not require this technique as they really should not be able to do anything that throws.

Quote:

---

I don't see the point in your insistence that its bad to teach a working, RAII following, standards reliant solution that could very well be used, and to my knowledge is used, at some level in so called safer things, in addition to the other crap you could use.

---

All in due time. You do not start with the complex things first. You start with the easy things first, then generalize it.
What someone doesn't know cannot cause any harm.

But as to the initial thing that sparked this... in situation with raw pointers, I do claim that catching and throwing is not a good solution. Especially not in the example.
From what I understand, that was one beef you had with the article.

I have reworded some things in the article. Perhaps you will this wording better.

Quote:

---

I have reworded some things in the article. Perhaps you will this wording better.

---

You've done nothing to appease me.

But my issue with the wiki as a whole is that its essentially your opinion dump now, and you publish entire articles and other people only find out about it when you link to them, because you also refuse to integrate your crap onto the wiki, like say on the main page. Not that it matters, because no one edits the wiki anymore, and thus, no one is there to keep you honest.

I do put links on the main page. When I write new things, it is because I do not believe there is a suitable other place.
Considering a lot of people are registered and can edit the wiki, it is not my fault that no one is. I doubt that moving it elsewhere would help.

So. We are at crossroads.
If you keep denouncing my articles, I will keep denouncing your claims.
What do we do?

Quote:

---

Originally Posted by Elysia

I do put links on the main page.

---

No you don't, and yet you link to them all the time: No one else knows about those pages until you do.

So it appears I remember wrong.
And yet, I wonder if people will even read the main page from time to time, or even the changes page which can be used to spot changes.
I could do it, but it would be of any benefit? If you would like me to do it in the future, I'll oblige, though.