DaniWeb Forum Index > Software Development > C++

C++ RSS

Insanity of Unix-land

Please support our C++ advertiser: Intel Parallel Studio Home

Thread Solved

•

Join Date: Jun 2009

Posts: 28

Reputation: PopeJareth is an unknown quantity at this point

Solved Threads: 3

PopeJareth PopeJareth is offline

Offline

Light Poster

Insanity of Unix-land

19 Days Ago

Can Someone tell me why these files won't compile on unix but work fine (mostly) in windows?

It looks like unix-land doesn't load the variables from the inherited class QueueArray into the proper scope.

prog5.cpp is supposed to create 3 different types of Deque classes.
each Deque inherits from ArrayQueue

Your help is greatly appreciated =)
Thanks everyone

Attached Files

	Deque.h (1.7 KB, 2 views)
	ArrayQueue.h (1.9 KB, 2 views)
	prog5.cpp (4.5 KB, 2 views)
	typescript.txt (7.0 KB, 1 views)
	prog5b.txt (187 Bytes, 1 views)

•

Join Date: Jan 2009

Posts: 306

Reputation: JasonHippy is a jewel in the rough

Solved Threads: 52

JasonHippy JasonHippy is offline

Offline

Posting Whiz

18 Days Ago

•

Originally Posted by PopeJareth

Can Someone tell me why these files won't compile on unix but work fine (mostly) in windows?

It looks like unix-land doesn't load the variables from the inherited class QueueArray into the proper scope.

prog5.cpp is supposed to create 3 different types of Deque classes.
each Deque inherits from ArrayQueue

Your help is greatly appreciated =)
Thanks everyone

One thing that immediately strikes me is that you are using #pragma once, which as far as I am aware is a preprocessor command that is used solely by Microsoft compilers. So perhaps using traditional inclusion guards might help here. e.g.

 Help with Code Tags 
 C++ Syntax (Toggle Plain Text) 
#ifndef SYMBOLNAME_DEFINED
#define SYMBOLNAME_DEFINED
 
// The rest of your header code goes here
 
#endif // SYMBOLNAME_DEFINED
#ifndef SYMBOLNAME_DEFINED
#define SYMBOLNAME_DEFINED

// The rest of your header code goes here

#endif // SYMBOLNAME_DEFINED

I'm thinking that because gcc doesn't recognise the #pragma command, it therefore sees no inclusion guards in your code. So perhaps that could be causing things to go a little screwy with gcc.

Also between lines 45 and 46 of the bool Deque<T>::dequeueBack(T &itemRef) function in "Deque.h" you need to add a 'return true', otherwise you'll get some errors or warnings from the compiler (in both *nix and microsoft environments.)

I've not got a *nix box in front of me at the moment, so I can't test this, but replacing all instances of '#pragma once' with traditional (gcc and MS compatible) inclusion guards and then adding the 'return true' to "Deque.h" would at least be a step in the right direction, if not the complete solution to your problem!

Anyway, give that a go and let me know how you get on!
Cheers for now,
Jas.

There are 10 types of people in this world.....
Those who understand binary .....
And those who don't!

•

Join Date: Jan 2009

Posts: 306

Reputation: JasonHippy is a jewel in the rough

Solved Threads: 52

JasonHippy JasonHippy is offline

Offline

Posting Whiz

18 Days Ago

Aha,
I've just fired up one of my linux boxes, I've created a project in codeblocks using your files. I've made my suggested changes and and tried compiling... And there are still compiler errors.

The problem seems to be regarding the base class members (from ArrayQueue.h) in the Deque class. For some reason g++ doesn't seem to recognise the protected members from ArrayQueue.h like front, back, count, items etc.

I'm not sure if there's a compiler switch to enable the compiler to recognise these correctly, but I've found that if you reference the base-class members using the 'this' pointer in Deque.h, then the compiler errors disappear.

Here's a snippet from Deque.h to show you what I mean:

 Help with Code Tags 
 C++ Syntax (Toggle Plain Text) 
template <class T>
bool Deque<T>::dequeueBack(T &itemRef){
	if (this->isEmpty()){//cannot dequeue
		//cout<<"Empty dequeueBack in Dequeue\n";
		return false;
	}
	else{//procede dequeuing
		itemRef= this->items[this->back];
		if (this->back==0)
			this->back = MaxQueue-1;
		else
			this->back--;
 
	}
	this->count--;
	return true;
}
template <class T>
bool Deque<T>::dequeueBack(T &itemRef){
	if (this->isEmpty()){//cannot dequeue
		//cout<<"Empty dequeueBack in Dequeue\n";
		return false;
	}
	else{//procede dequeuing
		itemRef= this->items[this->back];
		if (this->back==0)
			this->back = MaxQueue-1;
		else
			this->back--;

	}
	this->count--;
	return true;
}

Anyways, the program now compiles without errors or warnings on windows and *nix. A .zip is attached with my changes applied.

In order to ensure that my changes haven't introduced any bugs to your code (apologies if any have crept in there!); you might want to ensure that the program still works in the way you originally intended it to.

Cheers for now,
Jas.

[EDIT]
p.s. I'm fairly new to *nix programming myself...Up until recently I've only ever developed on Windows (so yes, I'm a bit wintarded!). The little *nix programming I have done so far has been for my own amusement.
Anyways, out of curiosity I've done a bit of digging on other forums on this matter and it seems that on *nix, the 'this->' syntax is the norm when attempting to access base class members in derived types.
As far as I understand it, when 'this' is used; if the G++ compiler cannot find a class member/variable in the local scope it will also look for it in any base classes.
I'm not sure if 'this' is needed to access the base class members of all derived types or whether it is only templates that require it.

Last edited by JasonHippy; 18 Days Ago at 7:50 am.

Attached Files