Thread: [Dev-C++] 'New Source File' bug
Open Source C & C++ IDE for Windows
Brought to you by:
claplace
|
From: Devin C. <dcc...@ya...> - 2002-02-15 20:20:30
|
I came across a bug in Dev-C++ 4 some time ago, and now it's gotten so annoying that I'm mentioning it in case no one else knows about it. When I create a new souce file in a large (15+ files) project, and use Save As to rename it, often Dev-C++ refuses to change the name in the project window (the one on the left.) So I don't know what it's saving, exactly. Furthermore, I often get phantom unnamed windows. Clicking on the 'Unnamed1' in the project window seemed to create new ones. Last time, I tried to chase them all these spurious windows down and X them out of existence. Then I saved and quit...causing a whole slew of red-X windows errors and 'runtime error' complaints. I've had other problems with Dev-C++'s file handling. Once it didn't save something it should have. (Fortunately it was only a short header file, which I could easily recreate from the .cpp.) The reason I used 'Save As' in the first place is that some time ago I had similar problems with selecting an unnamed file in the project window and trying to change its name. (I can't recall the exact details.) I'm having enough trouble with C++'s noodleheaded view of aggregate data objects; this really isn't helping. Any workarounds? Has the problem been tracked down? --Devin Carless _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
|
From: Ioannis V. <no...@ya...> - 2002-02-16 03:18:04
|
> -----Original Message----- > From: dev...@li... > [mailto:dev...@li...] On Behalf > Of Devin Carless > Sent: Friday, February 15, 2002 10:24 PM > To: dev...@li... > Subject: [Dev-C++] 'New Source File' bug > > > > I came across a bug in Dev-C++ 4 some time ago, and now > it's gotten so annoying that I'm mentioning it in case no one > else knows about it. When I create a new souce file in a > large (15+ files) project, and use Save As to rename it, > often Dev-C++ refuses to change the name in the project > window (the one on the left.) So I don't know what it's > saving, exactly. Furthermore, I often get phantom unnamed > windows. Clicking on the 'Unnamed1' in the project window > seemed to create new ones. Last time, I tried to chase them > all these spurious windows down and X them out of existence. > Then I saved and quit...causing a whole slew of red-X windows > errors and 'runtime error' complaints. > I've had other problems with Dev-C++'s file handling. Once > it didn't save something it should have. (Fortunately it was > only a short header file, which I could easily recreate from > the .cpp.) The reason I used 'Save As' in the first place is > that some time ago I had similar problems with selecting an > unnamed file in the project window and trying to change its > name. (I can't recall the exact details.) Be patient, Dev-C++ 5 is coming. > I'm having enough > trouble with C++'s noodleheaded view of aggregate data > objects; this really isn't helping. What trouble. Ioannis * Ioannis Vranos * Programming pages: http://www.noicys.d2g.com * Alternative URL: http://run.to/noicys |
|
From: Devin C. <dcc...@ya...> - 2002-02-16 16:16:55
|
> Be patient, Dev-C++ 5 is coming. Good. :) Though, bugs aside, I rather like Dev-C++ 4. > > I'm having enough > > trouble with C++'s noodleheaded view of aggregate data > > objects; this really isn't helping. > > > What trouble. Initializing an array/vector of objects, of which some of the members are consts. That was my first problem. My second was push_back() decided to stop working. (This led me to look somewhat askance at vectors, and I still see them as exceedingly finicky things.) Initializing a vector to anything interesting including constants without using push_back() is difficult; I ultimately solved the problem by ripping out almost every const in my project (not without some satisfaction) and using a Set() function. (I implemented a rudimentary sort of data protection by only allowing anything to be changed if the Name member was set to the constant NULLSTR.) I've also had problems initializing vectors from arrays. Vectors can be initialized in a wonderful panoply of ways, all of which are thoroughly useless for my purposes. It's recently occurred to me that this is probably a job for an overloaded assignment operator. I'm not certain how to do this for a vector (while vectors are finicky, templates are just plain sticky, and I haven't read much about them because I don't expect to need them for a while.) Most of my problems, I can see, stem from the fact that I learned (and loved) C long before ever setting eyes on C++. (My first reaction to C++ was 'They've turned something beautiful into a hideous bloated beast.') So I despise references with a hate the KKK can only dream of achieving, find consts to be a pain in the colon that extends all the way up the intestines, and find C++ is excessively schoolmarmish about initialization. (Don't get me wrong - I adore classes, inheritance, polymorphism and even strong typing. On the whole, it's a much better language. --Devin Carless (Wow. I didn't plan on ranting that much.) _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
|
From: Ioannis V. <no...@ya...> - 2002-02-16 16:48:57
|
> -----Original Message-----
> From: dev...@li...
> [mailto:dev...@li...] On Behalf
> Of Devin Carless
> Sent: Saturday, February 16, 2002 6:20 PM
> To: dev...@li...
> Subject: Re: [Dev-C++] 'New Source File' bug
>
> >
> > What trouble.
>
> Initializing an array/vector of objects, of which some of the
> members are consts. That was my first problem. My second
> was push_back() decided to stop working. (This led me to
> look somewhat askance at vectors, and I still see them as
> exceedingly finicky things.) Initializing a vector to anything
> interesting including constants without using push_back() is
> difficult; I ultimately solved the problem by ripping out almost
> every const in my project (not without some satisfaction)
> and using a Set() function. (I implemented a rudimentary
I currently have little knowledge of the standard library and i am
currrently learning about it (currently reading 16 chapter of TC++PL
Special Edition). But with as many as i know so far you can do many
things with vectors:
const vector<int>::size_type SIZE=100;
vector<int>array(SIZE);
for(vector<int>::size_type i==0; i<SIZE; i++)
array[i]=...;
Anyway i think it is our lack of knowledge, not vectors. When i finish
the 16th chapter i will resend an email telling you how you can to
assignments using vector constructors.
> sort of data protection by only allowing anything to be
> changed if the Name member was set to the constant
> NULLSTR.)
> I've also had problems initializing vectors from arrays.
> Vectors can be initialized in a wonderful panoply of ways,
> all of which are thoroughly useless for my purposes. It's
> recently occurred to me that this is probably a job for an
> overloaded assignment operator. I'm not certain how to
> do this for a vector (while vectors are finicky, templates are
> just plain sticky, and I haven't read much about them
> because I don't expect to need them for a while.)
I am confident that standard containers are better than built in arrays.
You can overload an operator as a global function
e.g.
vector<int> &operator=(vector<int>&a, const vector<int> &b)
{ ... }
or better define it as a template:
template <class T>
vector<T> &operator=(vector<T> &a, const vector<T> &b)
{ ... }
> Most of my problems, I can see, stem from the fact that
> I learned (and loved) C long before ever setting eyes on
> C++.
Yes, me too. But C++ is 10000% better. I suggest "The C++ Programming
Language" 3rd edition or Special Edition by Bjarne Stroustrup (the
creator of C++).
>(My first reaction to C++ was 'They've turned
> something beautiful into a hideous bloated beast.') So I
No it is better.
> despise references with a hate the KKK can only dream of
> achieving, find consts to be a pain in the colon that extends
> all the way up the intestines, and find C++ is excessively
> schoolmarmish about initialization. (Don't get me wrong - I
> adore classes, inheritance,
> polymorphism and even strong typing. On the whole,
> it's a much better language.
It is better. :)
Ioannis
* Ioannis Vranos
* Programming pages: http://www.noicys.d2g.com
* Alternative URL: http://run.to/noicys
|
|
From: Devin C. <dcc...@ya...> - 2002-02-17 16:43:23
|
> I currently have little knowledge of the standard library and i am
> currrently learning about it (currently reading 16 chapter of TC++PL
> Special Edition). But with as many as i know so far you can do many
> things with vectors:
Oh, I know. They're wonderful-looking things. I'm currently only
using them as fancy dynamic arrays.
But while you can do a lot with vectors, vectors can do a lot with
you. I had Vec.size() in a conditional, and the conditional
consistently got it wrong. It worked, however, when I replaced
Vec.size() with a variable, Size, which had been intialized to
Vec.size() a line before.
That's only one reason I'm very cautious with vectors.
> Anyway i think it is our lack of knowledge, not vectors. When i finish
> the 16th chapter i will resend an email telling you how you can to
> assignments using vector constructors.
There's a saying that goes 'It's a poor workman who blames his tools.'
And many times it's been my mistake; I'm a poor workman. But there
are other times when I've caught something funny going on. (push_back()
refusing to work was one of them.)
> I am confident that standard containers are better than built in arrays.
Absolutely true: the reason I'm using vectors is because arrays are
/worse./ The only thing I think arrays have to recommend them is that
they can be intialized like so:
char* frogs[4] = { "Green", "Tree", "Bull", "Muppet" };
(Yes, I know char* is frowned upon, but I've found some interesting
traps trying to initialize a string to a string constant of the form "Blah"
when passed as an argument.)
For my project, in which certain subclasses have great tracts of
constant data, this kind of initialization would be ideal.
> You can overload an operator as a global function
> e.g.
> vector<int> &operator=(vector<int>&a, const vector<int> &b)
> { ... }
Thank you :)
> or better define it as a template:
>
> template <class T>
> vector<T> &operator=(vector<T> &a, const vector<T> &b)
> { ... }
Templates I'm somewhat wary of; I'll deal with them when I have
to. Until then I'll stick with learning the ins and outs of what I /do/
know.
> Yes, me too. But C++ is 10000% better. I suggest "The C++ Programming
> Language" 3rd edition or Special Edition by Bjarne Stroustrup (the
> creator of C++).
Unfortunately, that's beyond my resources. I don't have the money and the
demand in the university/city library for books that teach C++ is total.
I've
only managed to scrounge the texts I'm working with by good fortune.
And despite what I might say, C++ is 10,000% better. Partially, I think,
because the old Kernighan and Ritchie paradigm of 'only stupid people make
mistakes - are you a stupid person?' has been replaced by the strong-type-
checking 'Everyone makes mistakes, we'll help you catch them' theory.
> It is better. :)
You've said it three times now - it must be true!
--Devin Carless
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
|
|
From: Ioannis V. <no...@ya...> - 2002-02-17 17:33:33
|
> -----Original Message-----
> From: dev...@li...
> [mailto:dev...@li...] On Behalf
> Of Devin Carless
> Sent: Sunday, February 17, 2002 6:47 PM
> To: dev...@li...
> Subject: Re: [Dev-C++] 'New Source File' bug
>
>
> Oh, I know. They're wonderful-looking things. I'm
> currently only using them as fancy dynamic arrays.
> But while you can do a lot with vectors, vectors can do a
> lot with you. I had Vec.size() in a conditional, and the
> conditional consistently got it wrong. It worked, however,
> when I replaced
> Vec.size() with a variable, Size, which had been intialized to
> Vec.size() a line before.
> That's only one reason I'm very cautious with vectors.
This is broken compiler. Did it happen with MINGW32?
Although i did not see any code, value wrapping may had occured.
E.g.
for(int i=0; i<Vec.size(); i++)
{ ...}
When variable i reached the maximum int value it may wrapped around
(according to the standard it is undefined behavior).
The correct & safe synatx is assuming Vec to be vector<int>:
for(vector<int>::size_type i=0; i<Vec.size(); i++)
{ ...}
> > Anyway i think it is our lack of knowledge, not vectors.
> When i finish
> > the 16th chapter i will resend an email telling you how you can to
> > assignments using vector constructors.
>
> There's a saying that goes 'It's a poor workman who blames
> his tools.' And many times it's been my mistake; I'm a poor
> workman. But there are other times when I've caught
> something funny going on. (push_back() refusing to work was
> one of them.)
This is broken implementation issue.
> > I am confident that standard containers are better than built in
> > arrays.
>
> Absolutely true: the reason I'm using vectors is because
> arrays are /worse./ The only thing I think arrays have to
> recommend them is that they can be intialized like so:
>
> char* frogs[4] = { "Green", "Tree", "Bull", "Muppet" };
>
> (Yes, I know char* is frowned upon, but I've found some
> interesting traps trying to initialize a string to a string
> constant of the form "Blah" when passed as an argument.)
> For my project, in which certain subclasses have great
> tracts of constant data, this kind of initialization would be ideal.
I am working using standard containers all the time and never
encountered any problem (except that MING doesn't support vector::at()
).
Ioannis
* Ioannis Vranos
* Programming pages: http://www.noicys.d2g.com
* Alternative URL: http://run.to/noicys
|
|
From: Devin C. <dcc...@ya...> - 2002-02-18 14:27:28
|
> This is broken compiler. Did it happen with MINGW32?
Yes. But then again I've also had the compiler telling me there are
undefined escape sequences in the middle of comments. (That one
went away after a reboot.)
> Although i did not see any code, value wrapping may had occured.
>
> E.g.
>
> for(int i=0; i<Vec.size(); i++)
> { ...}
Not likely; the largest vector I'm dealing with should have sixty-four
elements. (This one had eight.)
> > something funny going on. (push_back() refusing to work was
> > one of them.)
>
> This is broken implementation issue.
I've gotten the compiler to act in weird ways more than once. If
others aren't having similar problems, then I suspect my system is
possessed. (Dev-C++ won't work on my other machine, a Win95
486; everything it compiles crashes.)
> I am working using standard containers all the time and never
> encountered any problem (except that MING doesn't support vector::at()
> ).
For me, every day is a fight against whatever new and interesting
perversity the language, compiler or IDE will throw at me. :) Most of the
time it's just my inadequate command of the language; I'm learning C++
using a technique known colloquially as 'the Hard Way.'
--Devin Carless
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
|
|
From: Ioannis V. <no...@ya...> - 2002-02-18 15:08:26
|
> -----Original Message-----
> From: dev...@li...
> [mailto:dev...@li...] On Behalf
> Of Devin Carless
> Sent: Monday, February 18, 2002 4:31 PM
> To: dev...@li...
> Subject: Re: [Dev-C++] 'New Source File' bug
>
>
> > This is broken compiler. Did it happen with MINGW32?
>
> Yes. But then again I've also had the compiler telling me
> there are undefined escape sequences in the middle of
> comments. (That one
> went away after a reboot.)
Never had similar problems. Not even once.
>
> I've gotten the compiler to act in weird ways more than once. If
> others aren't having similar problems, then I suspect my system is
> possessed. (Dev-C++ won't work on my other machine, a Win95
> 486; everything it compiles crashes.)
! Never had any slight problem. It may be a virus.
>
> > I am working using standard containers all the time and never
> > encountered any problem (except that MING doesn't support
> vector::at()
> > ).
>
> For me, every day is a fight against whatever new and
> interesting perversity the language, compiler or IDE will
> throw at me. :) Most of the time it's just my inadequate
> command of the language; I'm learning C++
> using a technique known colloquially as 'the Hard Way.'
Either you do programming mistakes, either you have hardware or virus
problem.
Doesn't the following code execute properly at your system?
#include <iostream>
#include <vector>
int main()
{
using namespace std;
vector<int>v(5000);
for(vector<int>::size_type i=0; i<v.size(); i++)
v[i]=i;
for(vector<int>::size_type i=0; i<v.size(); i++)
v[i]=i*2+i;
vector<int>::const_iterator p=v.begin();
while(p!=v.end())
cout<<*p++<<"\n";
}
Ioannis
* Ioannis Vranos
* Programming pages: http://www.noicys.d2g.com
* Alternative URL: http://run.to/noicys
|
|
From: Devin C. <dcc...@ya...> - 2002-02-19 14:17:19
|
> > Yes. But then again I've also had the compiler telling me > > there are undefined escape sequences in the middle of > > comments. (That one > > went away after a reboot.) > > Never had similar problems. Not even once. My response was, "Cool. I broke its brain." > > I've gotten the compiler to act in weird ways more than once. If > > others aren't having similar problems, then I suspect my system is > > possessed. (Dev-C++ won't work on my other machine, a Win95 > > 486; everything it compiles crashes.) > > ! Never had any slight problem. It may be a virus. That hypothesis has the virtue of not having to resort to the supernatural. I generally don't have much trouble with anything else, though, and I've worked on other machines with individual quirks. If this is a virus it's a very subtle (and specific) one. It's possible some of my problems are caused by a) a large project and b) very little RAM (24 M.) With all the read/writes to the disk, something's bound to go awry. Many of the symptoms also (see below) seem to indicate a memory leak. > Either you do programming mistakes, either you have hardware > or virus problem. I had Dev-C++ crash a compile on me yesterday (I can't remember the exact title, but it referred to DEVCPP.EXE.) I tried again and it went perfectly well. I also had an untraceable ambiguous reference; I changed the name of the function and things were fine. (The compiler said the function, scaffold(void) was first defined in stl_vector.h, but a search found no trace of such an animal. The debugger kept taking me to a line in bstring, which also seemed to lack any function called scaffold().) Devin's Computational Chaos Theory : I don't believe that computers are the entirely deterministic systems they seem to be. Like the Newtonian universe, there are hard-and-fast laws explaining behaviour. But in any complex system chaos sets in. Maybe someone misset a system parameter when the system was set up two years ago. Maybe a sector on the disk is wonky, and that's where the machine puts its cache. All of these things build over time, and though each and every one they has a -reason-, they are still -inexplicable-. You could go into the machine and break things down and explain everything, but that's not practical. So these bugs remain inexplicable and, for all purposes, randomly caused. 1) All systems increase in buggyness with respect to time and their complexity. 2) All of these bugs have natural causes. 3) Many of these bugs will require an inordinate amount of effort and skill to trace. 4) Therefore, these are (practically) supernaturally caused. > Doesn't the following code execute properly at your system? Dunno. I have noticed that if certain things start going wrong, e.g., the error messages from the compiler come out garbled, that's a sign things might get worse. When the only error message is garbled, that's the time to reboot the machine. The gradual onset, with the problem solved by rebooting, makes me suspect a memory management problem. --Devin _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
|
From: Ioannis V. <no...@ya...> - 2002-02-19 20:19:55
Attachments:
memtest-86.zip
|
> -----Original Message----- > From: dev...@li... > [mailto:dev...@li...] On Behalf > Of Devin Carless > Sent: Tuesday, February 19, 2002 4:19 PM > To: dev...@li... > Subject: [Dev-C++] Computers, chaos, and the supernatural > > > My response was, "Cool. I broke its brain." :)) > That hypothesis has the virtue of not having to resort to > the supernatural. I generally don't have much trouble with > anything else, though, and I've worked on other machines with > individual quirks. If this is a virus it's a very subtle > (and specific) one. > It's possible some of my problems are caused by a) a large > project and > b) very little RAM (24 M.) With all the read/writes to the > disk, something's bound to go awry. Many of the symptoms > also (see below) seem to indicate a memory leak. > > > I had Dev-C++ crash a compile on me yesterday (I can't > remember the exact title, but it referred to DEVCPP.EXE.) I Yes it crashes some rare times after many recompilations. > tried again and it went perfectly well. I also had an > untraceable ambiguous reference; I changed the name of the > function and things were fine. (The compiler said the > function, scaffold(void) was first defined in stl_vector.h, > but a search found no trace of such an animal. The debugger Perhaps that function was used inside the implementation file which is probably precompiled. > kept taking me to a line in bstring, which also seemed to > lack any function called scaffold().) > > Devin's Computational Chaos Theory : > I don't believe that computers are the entirely > deterministic systems they seem to be. Like the Newtonian > universe, there are hard-and-fast laws explaining behaviour. > But in any complex system chaos sets in. Maybe someone > misset a system parameter when the system was set up two > years ago. Maybe a sector on the disk is wonky, and that's > where the machine puts its cache. All of these things build > over time, and though each and every one they has a -reason-, > they are still -inexplicable-. You could go into the machine > and break things down and explain everything, but that's not > practical. So these bugs remain inexplicable and, for all > purposes, randomly caused. > 1) All systems increase in buggyness with respect to time > and their complexity. > 2) All of these bugs have natural causes. > 3) Many of these bugs will require an inordinate amount of > effort and skill to trace. > 4) Therefore, these are (practically) supernaturally caused. Now you have come across me there is no way that your machine will keep doing such things and escape untouched (what a statement!). I *strongly* suuspect you have memory problems. I am sending you attached (and to all in the list) memtest-86 which i consider as the best memory testing program. It is freeware. Run it and tell me the results (let it run all the default tests). > > Doesn't the following code execute properly at your system? > > Dunno. I have noticed that if certain things start going > wrong, e.g., the error messages from the compiler come out > garbled, that's a sign things might get worse. When the only > error message is garbled, that's the time to reboot the > machine. The gradual onset, with the problem solved by > rebooting, makes me suspect a memory management problem. After performing the memory test and find memory problems, uninstall & reinstalll Dev-C++ together with the latest version of MINGW (http://www.mingw.org). Keep me informed of the results. Ioannis * Ioannis Vranos * Programming pages: http://www.noicys.d2g.com * Alternative URL: http://run.to/noicys |
|
From: Ioannis V. <no...@ya...> - 2002-02-19 12:07:53
|
> -----Original Message-----
> From: dev...@li...
> [ <mailto:dev...@li...>
mailto:dev...@li...] On Behalf
> Of Devin Carless
> Sent: Saturday, February 16, 2002 6:20 PM
> To: dev...@li...
> Subject: Re: [Dev-C++] 'New Source File' bug
>
> >
> > What trouble.
>
> Initializing an array/vector of objects, of which some of the
> members are consts. That was my first problem.
>[...]
> Initializing a vector to anything
> interesting including constants without using push_back() is
> difficult; I ultimately solved the problem by ripping out almost
> every const in my project (not without some satisfaction)
> and using a Set() function. (I implemented a rudimentary
> sort of data protection by only allowing anything to be
> changed if the Name member was set to the constant
> NULLSTR.)
> I've also had problems initializing vectors from arrays.
> Vectors can be initialized in a wonderful panoply of ways,
> all of which are thoroughly useless for my purposes. It's
> recently occurred to me that this is probably a job for an
> overloaded assignment operator. I'm not certain how to
> do this for a vector (while vectors are finicky, templates are
> just plain sticky, and I haven't read much about them
> because I don't expect to need them for a while.)
I can now provide you with more info on this. Consider the code:
#include <vector>
int main()
{
using std::vector;
vector<int>v1(100); // array of 100 ints. Built in types are
initialised to 0
vector<int>v2(100, 1); // array of 100 ints with value 1
v1.assign(10, 20); // Erase the previous elements and place ten 20s.
int array[]={1,2,3,4,5,6,7,8,9,10};
// one past the end
vector<int>v3(&array[0], &array[10]); // Creates v3 having the values
of array
v2=v3;
v1.assign(&array[0], &array[2]); // Make v1 contain 1,2 . v1.size()==2
now
vector<int>v4(v1); // Create an exact copy of v1
}
Ioannis
* Ioannis Vranos
* Programming pages: <http://www.noicys.d2g.com/>
http://www.noicys.d2g.com
* Alternative URL: <http://run.to/noicys> http://run.to/noicys
|
|
From: Devin C. <dcc...@ya...> - 2002-02-19 14:33:53
|
Message
I can now provide you with more info on this. Consider the code:
=20
Thank you - it's most helpful. I think it is time for me to rebuild =
the=20
initialization routines of my major objects.
int array[]=3D{1,2,3,4,5,6,7,8,9,10};
=20
// one past the end
vector<int>v3(&array[0], &array[10]); // Creates v3 having the values =
of array
Ooo. I didn't know you could do that. The -only- source I have for =
initializing vectors=20
in objects (ANSI-C++ won't let you specify a size if the vector is in =
an object) uses a=20
hack. The object's vector is declared without a size. In the =
constructor, a temp vector=20
is declared /with/ a size, and the object's vector is equated to it. =
When the constructor=20
ends, the temp vector goes out of scope. Problem solved, at the minor =
(hah) cost of=20
some clarity.
=20
|
|
From: Ioannis V. <no...@ya...> - 2002-02-19 20:23:05
|
<http://run.to/noicys> -----Original Message----- From: dev...@li... [mailto:dev...@li...] On Behalf Of Devin Carless Sent: Tuesday, February 19, 2002 4:37 PM To: dev...@li... Subject: Re: [Dev-C++] 'New Source File' bug int array[]={1,2,3,4,5,6,7,8,9,10}; // one past the end vector<int>v3(&array[0], &array[10]); // Creates v3 having the values of array Ooo. I didn't know you could do that. The -only- source I have for initializing vectors in objects (ANSI-C++ won't let you specify a size if the vector is in an object) Huh? :) ANSI C++ lets you specify the size of a vector in any circumstance. uses a hack. The object's vector is declared without a size. In the constructor, a temp vector is declared /with/ a size, and the object's vector is equated to it. This has large time cost. Also for large vectors it has large space cost too. When the constructor ends, the temp vector goes out of scope. Problem solved, at the minor (hah) cost of some clarity. Large time/space cost for large vectors. We must try to avoid changing the size of the vector as also creating temporary ones. You can initialize them as i said, why to do these dirty tricks anymore? :) Ioannis * Ioannis Vranos * Programming pages: <http://www.noicys.d2g.com/> http://www.noicys.d2g.com * Alternative URL: <http://run.to/noicys> http://run.to/noicys |