Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions concerning problems with code you've written must describe the specific problem — and include valid code to reproduce it — in the question itself. See SSCCE.org for guidance.
Closed 9 years ago.
Improve this question
when I declare a new queue object like that, the exe stop working：
arrayQueue myQueue;
myQueue.enqueue("111");
char* x=myQueue.dequeue();
cout<<x<<endl;
when I create the object using new, it works：
arrayQueue* myQueue=new arrayQueue();
myQueue->enqueue("111");
char* x=myQueue->dequeue();
cout<<x<<endl;
so what's the problem? the following code is a "queue" I wrote:
in .h head file：
class arrayQueue{
private:
array<char*,100> queueContrainer;
int maxSize;
int head;
int tail;
public:
arrayQueue();
~arrayQueue();
bool isEmpty();
bool isFull();
int getSize();
void enqueue(char*);
char* dequeue();
};
implementation in .cpp（only upload the constructor here：
arrayQueue::arrayQueue(){
head=0;
tail=0;
maxSize=100;
for(array<char*,100>::iterator it1=queueContrainer.begin();it1!=queueContrainer.end();++it1){
*it1="Empty";
}
}
main.cpp; arrayQueue.cpp; arrayQueue.h. three files to compile:
https://drive.google.com/file/d/0B5FCKG1I8ce0R1RORUFYWFhUN0E/edit?usp=sharing
https://drive.google.com/file/d/0B5FCKG1I8ce0QlBCTzdBUlJfZG8/edit?usp=sharing
https://drive.google.com/file/d/0B5FCKG1I8ce0SGdWOVg1RzNTNW8/edit?usp=sharing
Do you have a valid destructor? In the second example the object pointed to by myQueue is not deleted as it should, and the destructor never gets called.
In the first example myQueue is deleted when it goes out of scope, and the destructor will be called automatically. If your destructour is missing or buggy, the program will fail to compile or run.
In the first line
queue myQueue;
You are creating an object of type 'queue', possibly std::queue which has no 'enqueue' or 'dequeue' methods.
Related
Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 1 year ago.
Improve this question
I have the following code, in which I dynamically allocate memory, and then it deletes it two times in the destructor, causing an error. How can I go about fixing this?
(Nothing wrong, see edit below).
class Song {
private:
char *name;
public:
Song (char *name = "") {
this->name = new char[strlen(name)+1];
this->name[strlen(name)] = '\0';
strcpy(this->name, name);
}
~Song() {
cout << "DEST" << endl; // gets called 2 times, causing an error.
delete [] this->name;
}
};
class CD {
private:
Song songs[1];
public:
CD() {}
~CD() {}
};
int main() {
CD cd1;
Song song1("Song1");
return 0;
}
Edit:
It seems like this code doesn't actually have anything wrong.
The problem was in another part of my code: I used the = operator, but didn't have a copy assignment constructor. Thanks for your help suggesting the rule of three.
It doesn't delete your char array two times, it creates two instancies of your class, so it allocates memory for two strings, then it deletes this memory at destructor. There isn't any double free in your code, what could be the source of your problem (but shouldn't crash your program) is that you assign a string litteral to a char* which is deprecated in c++, you should instead use a const char* in the prototype of your constructor
Song (const char * name);
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 4 years ago.
Improve this question
I try to program an UPN Calculator in c++ with console input.
So I wrote a node and a stack class and use it in the main class. When starting everything goes well until I start pushing stuff on to the stack. I then get a "Access violation writing exception" and do not really understand what the problem is.
#include "pch.h"
#include "Node.h"
Node::Node(int value){this->value = value;}
int Node::GetValue(){return this->value;}
Node * Node::GetNode(){return this;}
Node* Node::GetNextNode(){return this->next_node;}
bool Node::SetNextNode(Node n)
{
this->next_node = &n;
return true;
}
Node * Node::GetBeforeNode(){return this->before_node;}
bool Node::SetBeforeNode(Node n)
{
this->before_node = &n; // <---- the error occures here
return true;
}
Don't create pointers to variables with local scopes.
Your Node n is passed to SetBeforeNode by value, so it's copied, you take it's address, but then n goes out of scope and you stay with dangling pointer, so instead of:
bool Node::SetBeforeNode(Node n)
it should be:
bool Node::SetBeforeNode(const Node& n)
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 5 years ago.
Improve this question
I have a class like this:
class Foo{
public:
Foo* next = nullptr;
Foo() = default;
Foo(Foo *next){
Foo::next = new Foo(*next);
}
Foo(const Foo ©){
next = new Foo(*copy.next);
}
~Foo(){
delete next;
}
}
It compiles, but when I instantiate the class anywhere, the program crashes. When using a debugger a "breakpoint trap" is triggerd at delete next.
Why is that?
Edit:
The problem was, that there were instances where next could be set to pointers created outside of the class. I assumed you could delete pointers created anywhere.
Your pointer next is uninitialized, pointing to something unknown. delete will (most likely, if you are lucky) throw trying to delete it. Make sure the pointer points to memory allocated with new or is a nullptr.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 6 years ago.
Improve this question
For example if we have 2 classes
class A{
int size;
A** arr;
}
class B{
int size;
A** arr;
}
For A's constructor I wrote:
A::A(){
this->arr=new A* [20];
}
For B's constructor I wrote:
B:B(){
this->arr=new A* [20];
}
For A's destroctor I wrote:
A:~A(){
for(int i=0;i<this->size;i++){
delete this->arr[i];
}
delete [] this->arr;
}
For B's destructor I wrote:
B:~B(){
for(int i=0;i<this->size;i++){
delete this->arr[i];
}
delete [] this->arr;
}
Note that the size will grow as I put more obj into the arr.
Now my question is, while I am testing, there's nothing wrong, but after the main program returns, it gives me segfault?
Seems to me like a classic case of not implementing the copy constructor and passing an instance by copy. You should really read an article or two about memory management in c++, or use shared_ptr/unique_ptr.
You should initialize size in the constructor, too.
A::A(){
this->size=20;
this->arr=new A* [20];
}
same for B
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 7 years ago.
Improve this question
I have implemented a stack in C++, but I have a problem with returning junks.
For example, I have:
...
template<class T>
T stack<T>::pop()
{
/* Verific dacă există elemente pe stivă */
if( isEmpty() )
{
T junk;
fprintf(stderr, "No data.\n");
return junk;
}
...
}
This is not the right way for solving the problem, because I will have a valgrind error. How can I solve it?
This is poor idea because (among other things) if T's copy constructor can throw, it can destroy data (removes item from stack, then copying to return the item throws, which destroys the copy).
One way to fix the problem is to change the interface to something like this:
void stack<T>::pop(T &ret) {
if (!isempty())
ret = data[top--];
}
Or, to provide an indication of whether it succeeded:
bool stack<T>::pop(T &ret) {
if (isempty())
return false;
ret = data[top];
--top;
return true;
}
This way, if the copy constructor throws, top is never decremented, so the item remains on the stack. If execution gets past that, the rest of the function can't throw, so we always either succeed completely (the item is copied to the proper destination and removed from the stack) or else the function has no effect at all (the item remains on the stack).