Re: [Flightgear-devel] const and copy constructor
Hmm...
Can you give a complete minimal example? I just tried the following
one, and this compiles without problems, as it should:
= snip ==
struct bar {} ;
struct foo {
foo( foo const rhs ) : p( rhs.p ) {}
bar* const p ;
} ;
= snip ==
Are you *using* the assignment operator for your class somewhere?
Cheers
-Gerhard
--
Gerhard Wesp o o Tel.: +41 (0) 43 5347636
Bachtobelstrasse 56 | http://www.cosy.sbg.ac.at/~gwesp/
CH-8045 Zuerich \_/ See homepage for email address!
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] MSVC
Wow, it works! Thanks a lot for your help... -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de Frederic Bouvier Envoyé : jeudi 9 décembre 2004 20:31 À : FlightGear developers discussions Objet : RE: [Flightgear-devel] MSVC Selon RENNUIT Antoine 203220 Thésard [EMAIL PROTECTED]: That works better, but I still have several errors : - what is fadmin project useful for? The true question is can I remove it, because it needs FLTK, and it's a painful task to install it correctly (no .lib, no .dll...). fgadmin is a utility project and can be removed - I have a problem with the exit function declaration in stdlib.h, it tells me it is a redefinition, any idea? edit glut.h, locate exit and then change the file to have : #if _MSC_VER = 1200 _CRTIMP __declspec(noreturn) void __cdecl exit(int); #else _CRTIMP void __cdecl exit(int); #endif instead of : _CRTIMP void __cdecl exit(int); that works only for MSVC 6 -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] const and copy constructor
I think it complains the class has no constructor other than the
copy one.
you should try to add one :
class MyClass {
public:
MyClass(AnotherClass *p); // constructor
MyClass(const MyClass mc); // copy constructor
private:
AnotherClass* const ptrToAnotherClass;
}
MyClass::MyClass(AnotherClass *p) :
ptrToAnotherClass(p)
{
// other assignments
}
I actually do have one, I just omitted it for clarity.
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] const and copy constructor
But I don't know at the moment, why Jons code doesn't work :( CU, Christian For the moment, I'll just make it non-const. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] const and copy constructor
Jon Berndt writes:
Can you give a complete minimal example? I just tried the
following one, and this compiles without problems, as it should:
See below.
Are you *using* the assignment operator for your class
somewhere?
Not that I know of.
see below
FGTable::FGTable(const FGTable t) :
PropertyManager(t.PropertyManager)
{
Type = t.Type;
colCounter = t.colCounter;
rowCounter = t.rowCounter;
tableCounter = t.tableCounter;
nRows = t.nRows;
nCols = t.nCols;
nTables = t.nTables;
Tables = t.Tables;
^^
try something like untested
Tables.resize(nTables);
for( i=0; inTables; ++i)
Tables[i] = t.Tables[i]
HTH
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] const and copy constructor
Alistair K Phipps writes: or use vector FGTable* rather than vector FGTable , Yes I prefer using this form too Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] FlightGear Aero Club site
kugelfang presented his FlightGear Aero Club site on http://forums.avsim.net/dcboard.php?az=show_topicsforum=198 today. http://www.static-lift.net/aero-club/main/home.html Maybe we'll get some nice WWI planes in the next time. :-) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] const and copy constructor
Alistair K Phipps writes: or use vector FGTable* rather than vector FGTable , Yes I prefer using this form too Norman I made a few small changes to use the pointer as described above by Alistair. That took care of the problem. Thanks guys. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ..mixing sceneries, was World scenery rebuild
On Thursday 09 December 2004 21:53, Martin Spott wrote: Lee Elliott wrote: However, the 'server' (dual PIII-650, 768 MB) is a simple IDE based system and the lan is bog-standard 100Mbit so it seems a little slower to me, than running with everything local. This doesn't surprise, because the network always adds latency to the process of loading the stuff - even on a gigabit-network and SCSI drives on the server side. In most cases the point is latency, not bandwidth, Martin. Heh:) because 99% of my data is held on a 'server' there's lot's of space on my 'workstation' system HDs... ...so all the server data is backed up onto the workstations. It'd just be bad practice to run apps i.e. FG, on the backup data though:) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] DAFIF Will No Longer Be Available to Public
On Friday, 10 December 2004 00:57, Nick Coleman wrote: The DoD is going to stop making DAFIF available to the public. I don't know TerraGear at all, but I thought I'd give a heads up just in case it uses it. I'm surprised someone else hasn't commented on this yet. Losing DAFIF access will be a pretty big blow to X-Plane and FlightGear. The DAFIF data is the primary source of global airports and navaid data that we use in FlightGear. It is not the only source of info but it is the primary source. The other sources are just little bits and pieces - nothing on a global scale like DAFIF. So we are now esentially stuck with a dataset that is going to age and get inaccurate as time goes on and things are updated and changed in the real world. Frequencies, new navaid equipment, etc. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Broadcast Address
- Original Message - From: Steven Beeckman [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Friday, December 10, 2004 2:08 PM Subject: Re: [Flightgear-devel] Broadcast Address Citeren John Wojnaroski [EMAIL PROTECTED]: I've been thinking of moving over to RTLinux (there is an open-source GPL'd version) in 2005. It fits nicely with the structure of the opengc display code. I'd like to mention RTAI (http://www.rtai.org), a Linux kernel patch to get the kernel working in real-time (even hard real-time!). RTAI is open source too, and even GPL if I remember correctly. I don't know how it fits with opengc, as I haven't found much info on the linux-port of OpenGC (which actually looks very interesting to me :-D). There is also http://www.rtlinux.org which links over to http://www.fsmlabs.com/ which has a version and source with a GPL license. Without going into a long recap of the history, there was a earlier version of OpenGC that ran under Linux that was my child. A few years back Damion made some major changes to the project and licensing to allow for commercial use in experimental aircraft. Something I was (am not) too keen on and that software was removed. For some pics of OpenGC running with FlightGear browse over to the Project page on the FG website. Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] RT Linux
- Original Message - From: Curtis L. Olson [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Friday, December 10, 2004 1:35 PM Subject: Re: [Flightgear-devel] Broadcast Address RTLinux might give you some additional fine grained timing tools to throw at the problem, but it's still a hard problem. You still have to detect a situation where you aren't going to finish drawing in time, reliably identify the reason you aren't finishing in time (fill rate? too much geometry? texture thrashing? running 3 other apps in the background on the machine?) and come up with some way to resolve the problem ... are you going to draw less geometry? Pull in the far clip plane, go to a lower LOD on some of your objects (which ones?) Your solution needs to directly address the cause of the problem our your fix might not help you. In practice you can probably find some trends and narrow the problem scope significantly, but it's still not easy. The motivation to try RTLinux is related more to the control/feedback problem than any graphics issues. What has been achieved running FG on off-the-self commodity PCs is remarkable. The problems/issues with glass displays are trivial by comparison. ATM the FG data rate is set at 30Hz in both directions using sockets configured for non-blocking udp datagrams. Since the nominal display rate is around 100fps for each opengc machine, they have no problem gobbling up all the packets. Conversely, the FMC is running as part of the display graph and pumping out udp control packets at whatever rate the opengc code is cycling. And the sim displays are simply exchanging data by sending out udp packets in a similar manner. All very simple, very messy, and very unorganized. How that impacts the control loops, gains, and responses to control commands is a big TBD. What has been happening is as the FG data rate is increased to say 45Hz, some latency has been creeping into the displays resulting in CIOs (computer-induced-oscillations) with the flight control system when the display rate drops due to increased number crunching and/or symbol generation and a higher rate of data exchange across the sim machines Thinking if I can broadcast a small timing packet or the data packet itself from FG and use that as a sync pulse for each machine on the sim side. Now each of those machines can begin processing for the current frame, exchange whatever state data for the current frame, and return required control commands before the start of the next frame or at least raise a flag if there is any frame slippage. Result is a more deterministic system sync'd to the FG cycle. Of course, still need to understand how and when FG and JSBSim exchange data across the property system(s). Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] const and copy constructor
Can you give a complete minimal example? I just tried the
following one, and this compiles without problems, as it should:
See below.
Are you *using* the assignment operator for your class
somewhere?
Not that I know of.
Cheers
-Gerhard
Header file for FGTable:
--- start ---
#include FGConfigFile.h
#include FGXMLElement.h
#include FGParameter.h
#include FGPropertyManager.h
#include sstream
#include vector
using std::vector;
using std::stringstream;
namespace JSBSim {
class FGTable : public FGParameter
{
public:
~FGTable();
FGTable(const FGTable table);
FGTable (FGPropertyManager* propMan, Element* el);
double GetValue(void) const {};
double GetValue(double key);
double GetValue(double rowKey, double colKey);
double GetValue(double rowKey, double colKey, double TableKey);
void operator(FGConfigFile);
void operator(stringstream);
FGTable operator(const double n);
FGTable operator(const int n);
inline double GetElement(int r, int c) {return Data[r][c];}
inline double GetElement(int r, int c, int t);
void Print(void);
private:
enum type {tt1D, tt2D, tt3D} Type;
double** Data;
vector FGTable Tables;
int nRows, nCols, nTables;
int colCounter, rowCounter, tableCounter;
int lastRowIndex, lastColumnIndex, lastTableIndex;
double** Allocate(void);
FGPropertyManager* const PropertyManager;
void Debug(int from);
};
}
--- end ---
Source file snippet:
--- start ---
FGTable::FGTable(const FGTable t) :
PropertyManager(t.PropertyManager)
{
Type = t.Type;
colCounter = t.colCounter;
rowCounter = t.rowCounter;
tableCounter = t.tableCounter;
nRows = t.nRows;
nCols = t.nCols;
nTables = t.nTables;
Tables = t.Tables;
Data = Allocate();
for (int r=0; r=nRows; r++) {
for (int c=0; c=nCols; c++) {
Data[r][c] = t.Data[r][c];
}
}
lastRowIndex = t.lastRowIndex;
lastColumnIndex = t.lastColumnIndex;
lastTableIndex = t.lastTableIndex;
}
--- end ---
The exact error message given from the Borland compiler is:
_algobase.h: E2125 Compiler could not generate operator= for class
'JSBSim::FGTable' in
function _STL::JSBSim::FGTable * __copyconst JSBSim::FGTable *,JSBSim::FGTable
*,int(const JSBSim::FGTable *,const JSBSim::FGTable *,JSBSim::FGTable *,const
random_access_iterator_tag ,int *) at line 145
The exact error message given from the gcc compiler in CygWin is:
g++ -I. -Isimgear/props -oFGTable.o -c FGTable.cpp
/usr/include/c++/3.3.1/bits/stl_algobase.h: In member function `
JSBSim::FGTable JSBSim::FGTable::operator=(const JSBSim::FGTable)':
/usr/include/c++/3.3.1/bits/stl_algobase.h:241: instantiated from `_OutputIter
std::__copy(_RandomAccessIter, _RandomAccessIter, _OutputIter,
std::random_access_iterator_tag) [with _RandomAccessIter = JSBSim::FGTable*,
_OutputIter =
JSBSim::FGTable*]'
/usr/include/c++/3.3.1/bits/stl_algobase.h:241: error: non-static const member
`JSBSim::FGPropertyManager* const JSBSim::FGTable::PropertyManager', can't
use default assignment operator
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] const and copy constructor
Jon Berndt wrote:
Are you *using* the assignment operator for your class
somewhere?
Not that I know of.
FGTable::FGTable(const FGTable t) :
PropertyManager(t.PropertyManager)
{
snip
Tables = t.Tables;
I think the problem is this assignment of vector FGTable which
involves assignment of individual FGTable instances. The default
operator= does not cope with copying non-static const members. You'll
either have to define:
const FGTable FGTable::operator=( const FGTable t )
{
// defn goes here
}
or use vector FGTable* rather than vector FGTable , depending on
what you're wanting to do.
Minimal code that demonstrates the problem:
#include vector
class A
{
public:
A( void* const p )
: _p( p )
{}
A(const A a)
: _p( a._p )
{ va = a.va; }
private:
std::vector A va;
void * const _p;
};
int main( void )
{
A *pa = new A( 0 );
A pa2 = *pa;
return 0;
}
HTH,
Alistair
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Broadcast Address
Let us know what you come up with on the broadcast stuff. Regards, Curt. I will do that... Your short discussion on timing brought to mind an interesting question. Since there is some unpredictability to the scheduling algorithms and device drivers and system calls, can the 60Hz rate really be locked. Short of going to a real-time OS like RTLinux, is this a case of where getting close is good enough... I've been thinking of moving over to RTLinux (there is an open-source GPL'd version) in 2005. It fits nicely with the structure of the opengc display code. Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Broadcast Address
John Wojnaroski wrote: I will do that... Your short discussion on timing brought to mind an interesting question. Since there is some unpredictability to the scheduling algorithms and device drivers and system calls, can the 60Hz rate really be locked. You are right, without taking additional measures, it's not really locked. The best you can hope for is that if you have enough hardware, and you don't throw too much rendering load at it, you can stay within your time slice limit and draw at 60 hz. You can cheat and if you realize you can't quite do 60hz, you can artificially thottle to some even divisor of that ... i.e. 30hz, 20hz, 15hz, etc. so that you are pretty much guaranteed to be locked at that rate, but you can never erase all certainty. A more sophisticated systems might be able to detect if you are having trouble sustaining 60hz and can perhaps tell if it's more of a fill rate problem or a geometry overload problem or some other problem, but you almost need a combination of hardware support, scene graph support, and application support to really do that well. High end sgi's have features where they can lower the pixel resolution of the screen sort of transparently so that you have less fill work to do, and can thus raise the frame rate back up if you are fill rate limited, I believe this can be done automatically at the hardware level. The scene get's blurrier, but your frame rates stay locked. The scene graph itself might be able to time your rendering phase and stop walking the scene graph when some time limit expires ... if you've sorted your geometry by priority, that might work well. At the application level you could tune texture usage, LOD, and other things to help make sure you hit your rendering speeds. I haven't dabbled much in these things though so I'm not an expert. There are probably other techniques or nuances that I'm not aware of. It's not an easy problem to deal with because performance bottlenecks can come at you from a lot of different direction, and you can't cleanly deal with it only in hardware, or only in the scene graph, or only in your application. For us poor folks on commodity hardware, we have to live with whatever we can do in the scene graph and application level and make blind assumptions about what the hardware will be able to do in the upcoming time slice. Short of going to a real-time OS like RTLinux, is this a case of where getting close is good enough... Personally, I think it all depends on how you define close, and how you define good enough. :-) If you can limit your drop outs to one every 60 seconds, that seems pretty close to perfection, is it good enough? Probably for 99.% of applications. If you are doing multiple displays, the bigger the gap between the displays, the more discrepancy you can tolerate. If you are edge blending projected displays, you have to have *much* tighter tolerances. If someone is piecing together some old hardware in their basement for fun and hobby, they might be perfectly happy with their side channels chunking along at 10-15fps, just because the added peripheral view gives them more than the jittery display takes away. I've been thinking of moving over to RTLinux (there is an open-source GPL'd version) in 2005. It fits nicely with the structure of the opengc display code. RTLinux might give you some additional fine grained timing tools to throw at the problem, but it's still a hard problem. You still have to detect a situation where you aren't going to finish drawing in time, reliably identify the reason you aren't finishing in time (fill rate? too much geometry? texture thrashing? running 3 other apps in the background on the machine?) and come up with some way to resolve the problem ... are you going to draw less geometry? Pull in the far clip plane, go to a lower LOD on some of your objects (which ones?) Your solution needs to directly address the cause of the problem our your fix might not help you. In practice you can probably find some trends and narrow the problem scope significantly, but it's still not easy. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Broadcast Address
Citeren John Wojnaroski [EMAIL PROTECTED]: I've been thinking of moving over to RTLinux (there is an open-source GPL'd version) in 2005. It fits nicely with the structure of the opengc display code. I'd like to mention RTAI (http://www.rtai.org), a Linux kernel patch to get the kernel working in real-time (even hard real-time!). RTAI is open source too, and even GPL if I remember correctly. I don't know how it fits with opengc, as I haven't found much info on the linux-port of OpenGC (which actually looks very interesting to me :-D). Greets, Steven ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] DAFIF Will No Longer Be Available to Public
On Sat, 11 Dec 2004 01:06:56 +0200, Paul Surgeon [EMAIL PROTECTED] wrote: I'm surprised someone else hasn't commented on this yet. We had a discussion a couple of months ago, when the topic first came up. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
