gamedevlists-windows Mailing List for gamedev (Page 30)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

> I assume you installed Service Pack 3 of W2K,

Yes.

> and the Service Pack 5 of VSS

Do you mean of VC ? Then yes.

Pierre Terdiman wrote:
> ...I am so bored....
>
> It just happened one more time : I was starring at the screen for a
> good minute, thinking hard about some design issues, when VC(6) just
> shut down. No warning, no message box, one frame later it's just not
> here anymore. And of course, all the delicate changes I had been
> doing in order to improve a design without breaking everything are
> gone, it didn't save the files.
> [...]
> Note that I'm a newbie on W2K. I've been forced to upgrade some weeks
> ago after a nasty virus actually killed my W98. I was otherwise very
> happy with it (used it for years, no real issues).

I assume you installed Service Pack 3 of W2K, and the Service Pack 5 of VSS
?

    Mickael Pointier

> Sorry, but this is nonsense. You are suggesting that anything the =
standard
> does not forbid explicitly is "fair game". The standard does not =
specify
> that, under no circumstances, should vector::push_back() format=20
> drive C. Are

It does specify the runtime behavior of push_back(), and it specifies=20
what program-visible state (using the standards library) is changed=20
through the function. If the contents of drive C is not program=20
visible using only the standards libraries, and you can format that=20
in the expected amortized runtime of push_back(), then that would be=20
a conformant (though useless) implementation.

Anyway, C++ is the new COBOL.

Cheers,

				/ h+

I thought vc 7.1 (vs.net 2003) supported partial template specialization ? 

> -----Original Message-----
> From: Parveen Kaler [mailto:pk...@al...]
> Sent: 14 June 2003 21:00
> To: gam...@li...
> Subject: RE: [GD-Windows] VC++ lag
> 
> 
> On Thu, 2003-06-12 at 13:05, David Notario wrote:
> > If you guys can provide a list things where vs can improve (from its
> > latest version), with arguments such as (X sucks because 
> this, this and
> > that. Blah doesn't work in this situation), I'll be happy to forward
> > your list of petitions to the VS team.
> 
> 
> Since no one else has mentioned it.  How about partial template
> specialization sometime soon?
> 
> I can live with most of the quirks of the IDE.
> 

On Thu, 2003-06-12 at 13:05, David Notario wrote:
> If you guys can provide a list things where vs can improve (from its
> latest version), with arguments such as (X sucks because this, this and
> that. Blah doesn't work in this situation), I'll be happy to forward
> your list of petitions to the VS team.

Since no one else has mentioned it.  How about partial template
specialization sometime soon?

I can live with most of the quirks of the IDE.

> Is there a particular part of the standard that clearly says that clear
> *must be implemented* as erase(begin(), end())?

It's at section 23.1.1 [lib.sequence.reqmts], and it clearly shows this as a
requirement for sequences, which therefore covers vector.

> Moreover, the point of standards (especially the C++ standard) is as
> much what they say and what they *do not* say.  Your argument that
> since it doesn't explicitly say clear() deallocates means that it should
> not is wrong.  There is a clear language in the standard of phrases
> like "should have" and "must have" and such that have well defined
> meanings.  Lack of specification is exactly that - something the
> standard fails to specify.

Sorry, but this is nonsense. You are suggesting that anything the standard
does not forbid explicitly is "fair game". The standard does not specify
that, under no circumstances, should vector::push_back() format drive C. Are
you suggesting that an implementation should therefore be allowed to
interpret this as a legal implementation detail? What happens is that people
read meanings into things which are not really there in order to support
their own arguments, so common sense has to prevail at some point. In this
case, common sense settled on "no deallocation" quite some time ago, and
then someone came along and threw that in the bin because it didn't suit
their own requirements.

> A similar argument used to occur with list<>::size() being O(N) on
> one implementation and O(1) on just about nearly every other
> implementation.

Doesn't surprise me. What was the outcome of this one?

> Luckily the next round of C++ standards (probably around 2020 at
> the current pace) should clearly define more implementation
> requirements of the STL, but I still doubt they will define allocation
> deallocation requirements.

I find it sad that the next standard is likely to be an order of magnitude
more complex, not due to new content, but mainly due to tightening up of the
language used to stop people taking liberties where it is pretty clear what
was meant in the first place.

- Neil.

> Even Stroustrup's 2nd edition C++ book is worse than worthless now!
> I have a book called "The STL <PRIMER>" which is similarly
> obsolete.  (I think Josuttis's book is great, by the way!)
> Think of all the C++ STL demo code without "using namespace std;"!

True, things change all the time, but the current C++ standard will not.
Stroustrup's 3rd edition is based on the final draft of the standard, and he
clearly states that a vector never shrinks, so it seems that he doesn't
think the standard is vague on this matter either.

> Ideally changes would never affect existing code.  The idea of
> Microsoft adding a "::deallocate()" method may have been a
> preferable alternative to changing "::clear()".  Microsoft
> would depart from STL in either case (if one accepts that
> ::clear() should not deallocate), but at least a new method
> is something that would not affect existing code, and there's
> always the chance that "STL 2" would one day appear, and
> Microsoft could advocate their "::deallocate()" method.

It would affect any code written using their non-standard extension which
you then tried to build on another compiler. That's what standards are for.
If they are not going to stick to them, why implement them in the first
place? The second option, advocating the addition of the method to the new
standard, is the way to go.

> But maybe the intention was to affect existing code!  Maybe
> making ::clear() do deallocation is a pragmatic solution to
> a serious problem plaguing 99% of the typical uses of vector.
> I'm not saying I would support something like that, but it
> would be the same kind of thinking that would lead a car
> company to lower safety standards and accept the increase in
> lawsuits because it ultimately lowered their costs.  If
> changing ::clear() reduces disk access due to swapping, and
> thus generally improves the performance of applications
> running under Windows, "it's worth giving developers one more
> gotcha to be aware of".

Yes, I'm pretty sure it was something like this that prompted them to make
the change. They probably thought that the average developer didn't
understand the no-shrink policy on vectors, and so decided it would be best
for most people if they changed it. Unfortunately, they didn't show any
concern for developers who took the time to understand exactly how it
worked, or developers who wanted to write portable code, or in fact anyone
who thinks that standards are worth a toss. They didn't even bother to
mention it as a change to watch out for when migrating from VC6.

> absurdity in allowing ::clear() to deallocate, so I think it
> was kind of irresponsible to *rely* on clear() to not do deallocate!
> Maybe most people didn't so much "rely" on not deallocating
> as much as become surprised by the slowdown when it does start
> deallocating!

No. What was irresponsible was changing the behaviour to something which is
illegal according to the standard. If anything, myself and others have been
complete saps for relying on standards to be worth anything.

- Neil.

=20
I'm not arguing for/against the change in VC7, but I read through good
chunks of the standard last night and found only a couple references
to the requirements of clear().  And each of those was in context of
running time and not implementation.
=20
Is there a particular part of the standard that clearly says that clear
*must be implemented* as erase(begin(), end())?
=20
Moreover, the point of standards (especially the C++ standard) is as
much what they say and what they *do not* say.  Your argument that
since it doesn't explicitly say clear() deallocates means that it should
not is wrong.  There is a clear language in the standard of phrases
like "should have" and "must have" and such that have well defined
meanings.  Lack of specification is exactly that - something the=20
standard fails to specify. =20
=20
A similar argument used to occur with list<>::size() being O(N) on=20
one implementation and O(1) on just about nearly every other=20
implementation. =20
=20
Luckily the next round of C++ standards (probably around 2020 at
the current pace) should clearly define more implementation=20
requirements of the STL, but I still doubt they will define allocation
deallocation requirements.
=20
Paul
=20

________________________________

From: gam...@li... on behalf of Neil =
Stewart
Sent: Sat 6/14/2003 6:25 AM
To: gam...@li...
Subject: Re: std::vector::clear (was: [GD-Windows] VS.net rants, was Re: =
VC++ lag)

> I think ::swap() is a lame way to "deallocate" a vector's
> memory.  It requires creating a temporary vector, swapping
> contents with the vector whose buffer you want to throw away,
> and then clobbering the temporary vector.  I find the idea
> of having to summon up a trashcan, trading its emptiness
> with the trash of another, and then destroying the trashcan
> is nutty!
>
> The vector class should have had a ::deallocate() method from
> the very beginning.

Yes it is lame and a deallocate() method, or something like it, would =
have
been better.

> Since it did not, and the ::swap() technique is lame, and
> clobbering the owner of vector instances is lame, and adding
> a new method to vector is lame, the least-lame option
> is to exploit the lack of implementation specification of
> ::clear().

My other post gives several reasons why this is a bad thing and, as I =
said,
I don't think there is a lack of specification in the standard on this
matter, something which is reflected in all the STLs I have seen, except =
for
the one in VC7.

The least lame option would be to leave things as they are for now, and =
fix
the problem in the forthcoming, new standard, but by adding something =
like
deallocate() and not changing clear().

> Sure, existing applications will suffer a speed hit when
> recompiled, but the fix is as easy as searching for
> "clear()" and replacing with "resize(0)".
>
> I know that the "ease of fixing" is not a justification for
> changing the historical implementation!

You're right, it's not a justification, so it isn't acceptable to just
change things and hope everyone realises that what they thought was true =
is
actually not the case. Think of all the C++ web pages out there, all the
books, and all the programmers that are working to an assumption =
(actually,
a specification) which is not being followed properly. It seems to me =
that
getting all of them to change is far more of an issue than sticking to =
the
accepted implementation and well-known swap() method for releasing the
memory.

> I think the new implementation of clear has a few benefits:
>
> (1) Reduce memory waste due to vectors keeping up to
>      (2 * max_bytes_needed) over their lifetimes;

Well, apart from the fact that people already know how to free the =
memory
used by a vector (the swap method), this won't work, because only one
implementation does this. It's a worthless feature, because you cannot =
rely
on it.

> (2) Make crashing due to stale pointers and references
>      more likely!  As it was(/is), when one did a clear()
>      of a vector, pointers to elements would still work
>      until the vector grew!  With a ::clear() that
>      deallocates, the probability of discovering stale
>      pointers and references increases.

I think you already know that this is a pretty ropey justification. ;)

> (3) Custom allocators and deallocators will now have a
>      better sense of actual required memory on an
>      ongoing basis.

What makes you think that?

> As far as I'm concerned, the idea of something only growing
> and never shrinking sounds like a black hole or a memory
> leak!

Well, you shouldn't be using vector then. That's what it is supposed to =
do,
and it's a very useful idiom for many applications.

> I think Microsoft faced tough choices:
> (a) Do nothing, and suffer the ever-expanding memory
>       consumption of vectors scattered all over code;

Or do nothing and - shock, horror - remain identical to every other
implementation.

- Neil.

-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=3D555

> You're right, it's not a justification, so it isn't acceptable to just
> change things and hope everyone realises that what they thought was true
is
> actually not the case. Think of all the C++ web pages out there, all the
> books, and all the programmers that are working to an assumption
(actually,
> a specification) which is not being followed properly. It seems to me that
> getting all of them to change is far more of an issue than sticking to the
> accepted implementation and well-known swap() method for releasing the
> memory.

Things are changing all the time.  I bought a new book on Linux driver
development two years ago, and the very first program in the entire
book, the "Hello, World!" of kernel modules, failed to compile due to
the relocation of header files.  Starting with a certain version of
Red Hat Linux, the technique of getting network stuff to work radically
changed -- lots of configuration files, etc, had been moved around.
HTTP is changing.  Java is changing.  PHP is changing.

Even Stroustrup's 2nd edition C++ book is worse than worthless now!
I have a book called "The STL <PRIMER>" which is similarly
obsolete.  (I think Josuttis's book is great, by the way!)
Think of all the C++ STL demo code without "using namespace std;"!

Ideally changes would never affect existing code.  The idea of
Microsoft adding a "::deallocate()" method may have been a
preferable alternative to changing "::clear()".  Microsoft
would depart from STL in either case (if one accepts that
::clear() should not deallocate), but at least a new method
is something that would not affect existing code, and there's
always the chance that "STL 2" would one day appear, and
Microsoft could advocate their "::deallocate()" method.
But maybe the intention was to affect existing code!  Maybe
making ::clear() do deallocation is a pragmatic solution to
a serious problem plaguing 99% of the typical uses of vector.
I'm not saying I would support something like that, but it
would be the same kind of thinking that would lead a car
company to lower safety standards and accept the increase in
lawsuits because it ultimately lowered their costs.  If
changing ::clear() reduces disk access due to swapping, and
thus generally improves the performance of applications
running under Windows, "it's worth giving developers one more
gotcha to be aware of".

Speaking of awareness, Stroustrup's 3rd edition C++ book does
not mention the "well-known swap() method for releasing the
memory" of a vector.  Stroustrup does propose that one can
free up memory by assigning a new value to a vector, but
how lame is his example:

    v = vector<int>(4,99);  ?

It's worse than the ::swap() idea -- unless creating and
initializing a new vector to replace the existing vector
makes additional sense to one's particular application.

Josuttis's book does mention the ::swap() trick briefly, and
I imagine that if I did a Google search for "STL vector deallocate"
or something like that, I am sure I would discover the ::swap()
trick.

But, at the same time, one would discover that one cannot
rely on "::clear()" NOT doing deallocation anymore...!

Anyhow, if it is really critical to an application that
a core function, class, or data struction work or look a
certain way, then it should be wrapped!  Maybe it's lame
to wrap something that itself was meant to be the end-all
and be-all of wrappers in the first place, like STL,
but one has to dial up the countermeasures to address
the paranoia.

To summarize, I agree that changes cost humanity a lot of
time and effort.  I am intrigued by what may have motivated
Microsoft to change ::clear()...Was it to address an
internal need?  At the same time I am wondering what
application does so much vector filling and clearing
that malloc() takes 10% of the CPU time.  Polygon buffers
that are adapting every frame?

I'm glad this topic came up.  In my opinion it is further
support for defensive programming.  I think it's safe to assume
"Sleep(10000)" won't be added to the implementation of cos()
any time in the future, but I don't see the same kind of
absurdity in allowing ::clear() to deallocate, so I think it
was kind of irresponsible to *rely* on clear() to not do deallocate!
Maybe most people didn't so much "rely" on not deallocating
as much as become surprised by the slowdown when it does start
deallocating!

--- Colin

cp...@ea...

> I think ::swap() is a lame way to "deallocate" a vector's
> memory.  It requires creating a temporary vector, swapping
> contents with the vector whose buffer you want to throw away,
> and then clobbering the temporary vector.  I find the idea
> of having to summon up a trashcan, trading its emptiness
> with the trash of another, and then destroying the trashcan
> is nutty!
>
> The vector class should have had a ::deallocate() method from
> the very beginning.

Yes it is lame and a deallocate() method, or something like it, would have
been better.

> Since it did not, and the ::swap() technique is lame, and
> clobbering the owner of vector instances is lame, and adding
> a new method to vector is lame, the least-lame option
> is to exploit the lack of implementation specification of
> ::clear().

My other post gives several reasons why this is a bad thing and, as I said,
I don't think there is a lack of specification in the standard on this
matter, something which is reflected in all the STLs I have seen, except for
the one in VC7.

The least lame option would be to leave things as they are for now, and fix
the problem in the forthcoming, new standard, but by adding something like
deallocate() and not changing clear().

> Sure, existing applications will suffer a speed hit when
> recompiled, but the fix is as easy as searching for
> "clear()" and replacing with "resize(0)".
>
> I know that the "ease of fixing" is not a justification for
> changing the historical implementation!

You're right, it's not a justification, so it isn't acceptable to just
change things and hope everyone realises that what they thought was true is
actually not the case. Think of all the C++ web pages out there, all the
books, and all the programmers that are working to an assumption (actually,
a specification) which is not being followed properly. It seems to me that
getting all of them to change is far more of an issue than sticking to the
accepted implementation and well-known swap() method for releasing the
memory.

> I think the new implementation of clear has a few benefits:
>
> (1) Reduce memory waste due to vectors keeping up to
>      (2 * max_bytes_needed) over their lifetimes;

Well, apart from the fact that people already know how to free the memory
used by a vector (the swap method), this won't work, because only one
implementation does this. It's a worthless feature, because you cannot rely
on it.

> (2) Make crashing due to stale pointers and references
>      more likely!  As it was(/is), when one did a clear()
>      of a vector, pointers to elements would still work
>      until the vector grew!  With a ::clear() that
>      deallocates, the probability of discovering stale
>      pointers and references increases.

I think you already know that this is a pretty ropey justification. ;)

> (3) Custom allocators and deallocators will now have a
>      better sense of actual required memory on an
>      ongoing basis.

What makes you think that?

> As far as I'm concerned, the idea of something only growing
> and never shrinking sounds like a black hole or a memory
> leak!

Well, you shouldn't be using vector then. That's what it is supposed to do,
and it's a very useful idiom for many applications.

> I think Microsoft faced tough choices:
> (a) Do nothing, and suffer the ever-expanding memory
>       consumption of vectors scattered all over code;

Or do nothing and - shock, horror - remain identical to every other
implementation.

- Neil.

>=20
> -----Original Message-----
> From: Jon Watte [mailto:hp...@mi...]=20
> Sent: Friday, June 13, 2003 7:55 PM
> To: gam...@li...
>=20
>=20
> * Is there a key for go-to-next-Find-In-All-Files-match ?
>=20
> I haven't found it. I don't like reaching for the mouse just to=20
> navigate my Find results. "Go to next task" does not do it; it only=20
> seems to work for compile errors etc.

Yes, there is. The default is (IIRC) Ctrl-F6 and Ctrl-Shift-F6. But
I always remap it to Alt-Down and Alt-Up. The GUI commands are
Edit.GotoNextLocation and Edit.GotoPreviousLocation. These commands
step through the build log and find in files results depending on
which of both is currently visible (wonder what happens if both are).

Carsten Orthbandt
Founder + Development Director
SEK SpieleEntwicklungsKombinat GmbH
http://www.sek-ost.de

Wenn ich Visionen habe, gehe ich zum Arzt. - Helmut Schmidt
=20

Ben Carter wrote:

Lots of stuff about SourceSafe that I wouldn't know about, happy CVS user 
that I am. But I've got one answer:

> 2) In fact, can the Solution Explorer jump-to-current-file behaviour
> be turned off? It's occasionally useful, but far more often just
> annoying.

Yes, it can. Options/Environment/Projects_and_Solutions has a checkbox for 
"Track Active Item in Solutions Explorer". Not sure if it had that in the 
first one, but it's in 2003.

> 7) Can we have an option to turn off the task list? It's just a
> pointless recap of the information in the build window (usually with
> the important bits missing), and more often than not you spot the
> error in the build window, go to read it and... blam, you're looking
> at the task list instead because the build just aborted.

In the same Option dialog, "Show Task List window if build finishes with 
errors", seems to be new with 2003.

Enno.

I think ::swap() is a lame way to "deallocate" a vector's
memory.  It requires creating a temporary vector, swapping
contents with the vector whose buffer you want to throw away,
and then clobbering the temporary vector.  I find the idea
of having to summon up a trashcan, trading its emptiness 
with the trash of another, and then destroying the trashcan
is nutty!

The vector class should have had a ::deallocate() method from
the very beginning.

Since it did not, and the ::swap() technique is lame, and 
clobbering the owner of vector instances is lame, and adding
a new method to vector is lame, the least-lame option
is to exploit the lack of implementation specification of
::clear().

Sure, existing applications will suffer a speed hit when 
recompiled, but the fix is as easy as searching for 
"clear()" and replacing with "resize(0)".

I know that the "ease of fixing" is not a justification for
changing the historical implementation!

I think the new implementation of clear has a few benefits:

(1) Reduce memory waste due to vectors keeping up to 
     (2 * max_bytes_needed) over their lifetimes;

(2) Make crashing due to stale pointers and references
     more likely!  As it was(/is), when one did a clear()
     of a vector, pointers to elements would still work
     until the vector grew!  With a ::clear() that 
     deallocates, the probability of discovering stale
     pointers and references increases.

(3) Custom allocators and deallocators will now have a
     better sense of actual required memory on an
     ongoing basis.

As far as I'm concerned, the idea of something only growing
and never shrinking sounds like a black hole or a memory
leak!

I think Microsoft faced tough choices:
(a) Do nothing, and suffer the ever-expanding memory 
      consumption of vectors scattered all over code;
(b) Add a ::deallocate() method to vector, and experience
      the paranoia and wrath of cross-platform users of
      STL;
(c) Change ::clear() to do deallocation and suffer the
      wrath and paranoia of cross-platform users of STL
      who relied on the *implementation* of ::clear()
      operating a certain way;

Perhaps Microsoft will one day employ AIs in their workforce,
and so some poor AI can take the fall when the public gets
enraged.  This would bring new meaning to employee 
"termination"!  Of course, they would just reboot the 
employee to give it a new process ID, and thus flush away
liability without affecting productivity.  "Sure, PID 1337
put spyware and crash-hooks in IE 10.0, but PID 1337 was...
fired."

--- Colin

cp...@ea...

> It sounds to me like you were relying on an implementation dependency.
> My copy of "C++ Standard Library" by Josuttis just says that both of
> these will remove all the elements of the vector.  AFAIK, the standard
> makes no requirements about allocation/deallocation behavior for these
> operations, but I would expect both to potentially deallocate memory
> when I delete the whole vector.  If you want to clear the vector
> without changing its allocation, you should do vector::resize(0) IMO.

I don't agree with this, for several reasons:

1. The standard says that clear() is simply erase(begin(), end()), with a
post-condition of size()==0. It does not say that you can implement it any
other way, and this implementation (a Dinkumware variant) does exactly that:
it calls _Tidy(), so it is not following the standard on that score.

2. While the standard does not appear to say that erase() must not
deallocate memory, it very explicitly states that insert() will allocate
memory if required, and it is also very clear that resize() and reserve()
should never reduce capacity() (i.e. deallocate memory). In other words, I
believe the standard tells you what *will* happen during any operation and
if it does not mention something, it means that it *will not* happen, not
that "anything goes". You would have to be pretty anal to take this any
other way, which is what I think Dinkumware have done.

3. Stroustrup says explicitly in "The C++ Programming Language" that a
vector will never shrink, only grow. If the standard disagrees with this,
then why, and why is it still in his book?

4. It is far more consistent to make erase() (and therefore clear(), due to
point 1) operate in exactly the same manner as everything else in the
vector, including reserve() and resize(), none of which reduce the memory
used by the vector(). Every implementation I have seen does indeed treat
erase() in the same, consistent manner, and only the Dinkumware one differs
when it comes to clear(). It seems that everyone else has read the standard
to mean that a vector will not shrink.

5. The original Dinkumware STL used in VC6 uses erase(begin(), end()), and
is consistent with everything else in this respect. The fact that they have
since changed this defies belief. The only reason I can think of is that
they observed that many programmers were wasting a lot of memory on vectors
and thought they could "optimise" applications by making clear() deallocate.
The ironic thing is that they have actually hurt a lot of applications that
were relying on non-deallocation for performance reasons.

6. From an implementation perspective, there is very little to gain from
deallocating on clear() because you cannot assume that it *will* deallocate
on all implementations, so you must always use other methods (e.g. swap())
to ensure deallocation when you require it. All they have achieved is to
change the performance characteristics of the STL, which is deplorable,
because clearly defined performance characteristics are one of the main
features of the library.

7. Every implementation I have ever seen maintains capacity() on a clear().
For Dinkumware to say "sod what every other implementation has done for
years" is quite offensive in my book and is another reaosn people will be
able to spout about not using the STL. They have actually *damaged* standard
C++ by doing this. The standard _may_ be unclear on this situation, but
common practice is not so, if in doubt, they should have stuck with that.

8. Many, many people (including Stroustrup, it would appear) work on the
assumption that no STL implementation ever deallocates on a clear(). Even if
Dinkumware could argue that the standard does not actually say this, they
cannot ignore the fact that a lot of people are assuming that this is the
case. Doing so was very irresponsible IMO.

I could go on, but I think the important point is that Dinkumware have done
*no good* by taking this step, and clear() should be changed back to its
original form in future releases.

- Neil.

> > For some reason, they have changed the functionality of vector::clear()
to
> > actually deallocate memory, rather than simply doing erase(begin(),
end()),
> > which leaves the memory allocated.
>
> It sounds to me like you were relying on an implementation dependency.
> My copy of "C++ Standard Library" by Josuttis just says that both of
> these will remove all the elements of the vector.  AFAIK, the standard
> makes no requirements about allocation/deallocation behavior for these
> operations, but I would expect both to potentially deallocate memory
> when I delete the whole vector.  If you want to clear the vector
> without changing its allocation, you should do vector::resize(0) IMO.

Suppose the author of a popular library changed the implementation of the
sin() function to include Sleep(10000).  Ah, it was a mistake for the
programmer to DEPEND on the timing of the sin() function!  ;-)

Still, I like the idea of vector::clear() deallocating memory.  I think
that should have been the explicit specification all along.  Using
vector::resize(0) would have become a well-known optimization for avoiding
future malloc() calls when the same vector is drained and filled to a
similar level of capacity numerous times.

If vector::clear() didn't guarantee deallocation, then would the only
alternative be to clobber the object that contained the vector?
(Wouldn't calling the destructor explicitly be bad?)

Anyhow, unless I'm misunderstanding something, I'm glad for the
change.  I never liked the idea of memory sticking around,
and the memory persisting as the maximum size of all previous
uses of that vector.  Sure, I can clobber the object that owns
the vector, but sometimes that doesn't seem appropriate.

The weird thing is DEPENDING on the NEW implementation of
vector::clear() is just as bad as depending on the old implementation.
It's a shame, because vector::clear() becomes a useless method --
unless users of vector::clear() can hope that the implementation
will do what is statistically best for the platform.  Could it
be said that doing deallocation is an improvement under the
Windows platform?  Apparently not for some people.  But maybe
the dominant use of vector benefits from the deallocation behavior.

Still, I could imagine a persisting vector getting a spike of
stuff to fill it, getting cleared, and yet holding on to a huge
amount of memory.  Maybe it's bad design to keep the vector
around after it was drained after a big spike.

I suppose profiling memory and speed performance will always
reveal what is really important for an application, and the design
can be changed to respond to the reality of the current circumstances.

--- Colin

cp...@ea...

> > [1] I guess this will only ever happen to any person
> > once, but it sure is shocking:
> >
> >     Deleting files from the project deletes the source
> >     files themselves!
>
> This doesn't happen with all projects all the time.  It depends on how
> the files are included in the project.  It is documented under Visual
> Studio .NET / Developing with Visual Studio .NET / Managing Solutions,
> Projects, and Files / Solutions as Containers / Projects as Containers
> / Item Management in Projects.
>
> You do read the documentation on a new product before you start using
> it, don't you? ;-)

Let's just say that Microsoft gave notice about their plans to destroy
my files just as the Vogons gave notice of the destruction of the Earth
in "Hitchhiker's Guide to the Galaxy" (Douglas Adams):

Vogon:  There's no point in acting all surprised about it. All the planning
        charts and demolition orders have been on display in your local
        planning department on Alpha Centauri for fifty of your Earth years,
        so you've had plenty of time to lodge any formal complaint and it's
        far too late to start making a fuss about it now.

    [...]

Vogon:  What do you mean you've never been to Alpha Centauri? For heaven's
        sake mankind, it's only four light years away you know. I'm sorry,
        but if you can't be bothered to take an interest in local affairs
        that's your own lookout. Energise the demolition beams.

This parallels Arthur Dent's experience of the notice of the plan to
demolish his house:

- ...You hadn't exactly gone out of your way to call attention to them
    had you? I mean like actually telling anyone or anything.'
- But the plans were on display...'
- On display? I eventually had to go down to the cellar to find them.'
- That's the display department.'
- With a torch.'
- Ah, well the lights had probably gone.'
- So had the stairs.'
- But look you found the notice didn't you?'
- Yes,' said Arthur, `yes I did. It was on display in the bottom of a
    locked filing cabinet stuck in a disused lavatory with a sign on the
    door saying "Beware of The Leopard".

--- Colin

cp...@ea...

In article <6C3...@RE...>,
    "David Notario" <dno...@mi...>  writes:

> I would say the default setting is wrong.

AFAIK, its not a setting, its a property of the project IDE.
C#/VB.Net projects apparently don't use links, i.e. the project item
-is- the file, while C++ projects do use links, i.e. deleting the
project item doesn't touch the file.
-- 
"The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ:
          <http://www.xmission.com/~legalize/book/>
        izfree: Open source tools for Windows Installer
                <http://izfree.sourceforge.net>

On Friday, June 13, 2003, 7:18:54 PM, someone wrote:

>> 7) Can we have an option to turn off the task list?

> Options/Environment/Project And Solutions.

 Ah ha - thanks!

-- 
Ben Carter - Neko Technologies - be...@gu...
http://www.neko-tech.com/ - http://www.absoluteterror.com/
---------------------------------PGP Key available on request---
"Broken mirror, a million shades of light,
 the old echo fades away. 
 But just you and I can find the answer, 
 and then we can run to the end of the world."
                                - Small of two pieces, Xenogears

Oh, and I'll second the person who mentioned the breaking of project file
compatiblity between versions.

Please stop, there's no good reason for it and in situations where people
are forced to use a certain version (e.g XBox development) it's down right
annoying since everyone else has to follow, or people need to use different
version for different things.

Andy @
Climax Brighton

> -----Original Message-----
> From: Andrew Grant 
> Sent: Friday, June 13, 2003 11:19 AM
> To: 'gam...@li...'
> Subject: RE: [GD-Windows] VS.net rants, was Re: VC++ lag
> 
> 
> > 7) Can we have an option to turn off the task list?
> 
> Options/Environment/Project And Solutions.
> 
> 
> One thing related to this I'd like, less crap at the end of 
> the build window. After the last error there seems to be 
> about 10 lines of fluff which are either blank lines or could 
> be condensed into one line. As it is there'ss just enough to 
> make any errors scoll up out of sight, annoying.
> 
> Andy @
> Climax Brighton
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: Ben Carter [mailto:be...@gu...]
> > Sent: Friday, June 13, 2003 11:12 AM
> > To: Enno Rehling
> > Subject: Re: [GD-Windows] VS.net rants, was Re: VC++ lag
> > 
> > 
> > On Friday, June 13, 2003, 1:44:24 PM, someone wrote:
> > 
> > > I can add a few cents here, too...
> > 
> >  ...and a "few" more...
> > 
> > 1) Various source-control operations cause the Solution Explorer to
> > spend several minutes jumping randomly between files in the project
> > (apparently opening/closing/saving them or whatever) if you 
> have many
> > windows open.
> > 
> > 2) In fact, can the Solution Explorer jump-to-current-file behaviour
> > be turned off? It's occasionally useful, but far more often just
> > annoying.
> > 
> > 3) Editing multiple project properties at once is buggy, as 
> is editing
> > multiple configurations - frequently the properties window
> > mysteriously looses changes, vanishes altogether, displays 
> "there are
> > no properties for the selected item", or, in extreme cases, simply
> > crashes VS.net entirely. I've had to edit the .vcproj files 
> by hand a
> > couple of times to make changes thanks to this...
> > 
> > 4) If you do a "get latest" from within Sourcesafe recursively, and
> > several .vcproj files are updates, then VS.net only notices 
> the first
> > one that's changed, and blindly goes on using the others without
> > reloading them.
> > 
> > 5) "Get latest" from within the IDE is useless because it seems to
> > operate on the *current* .vcproj file, not the one in 
> Sourcesafe (or a
> > merge of the two), and hence misses newly-added files.
> > 
> > 6) Custom build step dependencies are crippled - it seems 
> > impossible to
> > set up a configuration that allows (for example) compiling a vertex
> > shader and then "incbin-ing" the resulting bytecode into a 
> header file
> > for inclusion in the project in such a way that everything rebuilds
> > correctly without resorting to multiple rebuilds and/or abuse of
> > "touch" on things.
> > 
> > 7) Can we have an option to turn off the task list? It's just a
> > pointless recap of the information in the build window (usually with
> > the important bits missing), and more often than not you spot the
> > error in the build window, go to read it and... blam, you're looking
> > at the task list instead because the build just aborted.
> > 
> > 8) An option to suppress the comments dialog when checking out files
> > would be good. We never use them, but I've lost track of how many
> > checkouts now have comments along the lines of "nt blah=0;" because
> > we're all used to just hitting ENTER to clear the "check out now?"
> > prompt...
> > 
> > 9) I haven't tried too hard to make this work so it could just be a
> > misplaced setting, but Japanese SJIS text support in the editor is
> > broken (it worked in VC6).
> > 
> > 10) And yes, yet another plea for a one-step "show settings for
> > current project and build" button. And, if possible, a convenient
> > way to change the "Debug->Command line parameters" setting for the
> > current project (in fact, the option to have that as a edit 
> box on the
> > toolbar would be best).
> > 
> >  ...er.. I think I'll stop now ^-^;
> > 
> > -- 
> > Ben Carter - Neko Technologies - be...@gu...
> > http://www.neko-tech.com/ - http://www.absoluteterror.com/
> > ---------------------------------PGP Key available on request---
> > "Broken mirror, a million shades of light,
> >  the old echo fades away. 
> >  But just you and I can find the answer, 
> >  and then we can run to the end of the world."
> >                                 - Small of two pieces, Xenogears
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.NET email is sponsored by: eBay
> > Great deals on office technology -- on eBay now! Click here:
> > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> > _______________________________________________
> > Gamedevlists-windows mailing list
> > Gam...@li...
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> > Archives:
> > http://sourceforge.net/mailarchive/forum.php?forum_id=555
> > 
> 

> 7) Can we have an option to turn off the task list?

Options/Environment/Project And Solutions.

One thing related to this I'd like, less crap at the end of the build
window. After the last error there seems to be about 10 lines of fluff which
are either blank lines or could be condensed into one line. As it is
there'ss just enough to make any errors scoll up out of sight, annoying.

Andy @
Climax Brighton

> -----Original Message-----
> From: Ben Carter [mailto:be...@gu...]
> Sent: Friday, June 13, 2003 11:12 AM
> To: Enno Rehling
> Subject: Re: [GD-Windows] VS.net rants, was Re: VC++ lag
> 
> 
> On Friday, June 13, 2003, 1:44:24 PM, someone wrote:
> 
> > I can add a few cents here, too...
> 
>  ...and a "few" more...
> 
> 1) Various source-control operations cause the Solution Explorer to
> spend several minutes jumping randomly between files in the project
> (apparently opening/closing/saving them or whatever) if you have many
> windows open.
> 
> 2) In fact, can the Solution Explorer jump-to-current-file behaviour
> be turned off? It's occasionally useful, but far more often just
> annoying.
> 
> 3) Editing multiple project properties at once is buggy, as is editing
> multiple configurations - frequently the properties window
> mysteriously looses changes, vanishes altogether, displays "there are
> no properties for the selected item", or, in extreme cases, simply
> crashes VS.net entirely. I've had to edit the .vcproj files by hand a
> couple of times to make changes thanks to this...
> 
> 4) If you do a "get latest" from within Sourcesafe recursively, and
> several .vcproj files are updates, then VS.net only notices the first
> one that's changed, and blindly goes on using the others without
> reloading them.
> 
> 5) "Get latest" from within the IDE is useless because it seems to
> operate on the *current* .vcproj file, not the one in Sourcesafe (or a
> merge of the two), and hence misses newly-added files.
> 
> 6) Custom build step dependencies are crippled - it seems 
> impossible to
> set up a configuration that allows (for example) compiling a vertex
> shader and then "incbin-ing" the resulting bytecode into a header file
> for inclusion in the project in such a way that everything rebuilds
> correctly without resorting to multiple rebuilds and/or abuse of
> "touch" on things.
> 
> 7) Can we have an option to turn off the task list? It's just a
> pointless recap of the information in the build window (usually with
> the important bits missing), and more often than not you spot the
> error in the build window, go to read it and... blam, you're looking
> at the task list instead because the build just aborted.
> 
> 8) An option to suppress the comments dialog when checking out files
> would be good. We never use them, but I've lost track of how many
> checkouts now have comments along the lines of "nt blah=0;" because
> we're all used to just hitting ENTER to clear the "check out now?"
> prompt...
> 
> 9) I haven't tried too hard to make this work so it could just be a
> misplaced setting, but Japanese SJIS text support in the editor is
> broken (it worked in VC6).
> 
> 10) And yes, yet another plea for a one-step "show settings for
> current project and build" button. And, if possible, a convenient
> way to change the "Debug->Command line parameters" setting for the
> current project (in fact, the option to have that as a edit box on the
> toolbar would be best).
> 
>  ...er.. I think I'll stop now ^-^;
> 
> -- 
> Ben Carter - Neko Technologies - be...@gu...
> http://www.neko-tech.com/ - http://www.absoluteterror.com/
> ---------------------------------PGP Key available on request---
> "Broken mirror, a million shades of light,
>  the old echo fades away. 
>  But just you and I can find the answer, 
>  and then we can run to the end of the world."
>                                 - Small of two pieces, Xenogears
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by: eBay
> Great deals on office technology -- on eBay now! Click here:
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555
> 

On Friday, June 13, 2003, 1:44:24 PM, someone wrote:

> I can add a few cents here, too...

 ...and a "few" more...

1) Various source-control operations cause the Solution Explorer to
spend several minutes jumping randomly between files in the project
(apparently opening/closing/saving them or whatever) if you have many
windows open.

2) In fact, can the Solution Explorer jump-to-current-file behaviour
be turned off? It's occasionally useful, but far more often just
annoying.

3) Editing multiple project properties at once is buggy, as is editing
multiple configurations - frequently the properties window
mysteriously looses changes, vanishes altogether, displays "there are
no properties for the selected item", or, in extreme cases, simply
crashes VS.net entirely. I've had to edit the .vcproj files by hand a
couple of times to make changes thanks to this...

4) If you do a "get latest" from within Sourcesafe recursively, and
several .vcproj files are updates, then VS.net only notices the first
one that's changed, and blindly goes on using the others without
reloading them.

5) "Get latest" from within the IDE is useless because it seems to
operate on the *current* .vcproj file, not the one in Sourcesafe (or a
merge of the two), and hence misses newly-added files.

6) Custom build step dependencies are crippled - it seems impossible to
set up a configuration that allows (for example) compiling a vertex
shader and then "incbin-ing" the resulting bytecode into a header file
for inclusion in the project in such a way that everything rebuilds
correctly without resorting to multiple rebuilds and/or abuse of
"touch" on things.

7) Can we have an option to turn off the task list? It's just a
pointless recap of the information in the build window (usually with
the important bits missing), and more often than not you spot the
error in the build window, go to read it and... blam, you're looking
at the task list instead because the build just aborted.

8) An option to suppress the comments dialog when checking out files
would be good. We never use them, but I've lost track of how many
checkouts now have comments along the lines of "nt blah=0;" because
we're all used to just hitting ENTER to clear the "check out now?"
prompt...

9) I haven't tried too hard to make this work so it could just be a
misplaced setting, but Japanese SJIS text support in the editor is
broken (it worked in VC6).

10) And yes, yet another plea for a one-step "show settings for
current project and build" button. And, if possible, a convenient
way to change the "Debug->Command line parameters" setting for the
current project (in fact, the option to have that as a edit box on the
toolbar would be best).

 ...er.. I think I'll stop now ^-^;

-- 
Ben Carter - Neko Technologies - be...@gu...
http://www.neko-tech.com/ - http://www.absoluteterror.com/
---------------------------------PGP Key available on request---
"Broken mirror, a million shades of light,
 the old echo fades away. 
 But just you and I can find the answer, 
 and then we can run to the end of the world."
                                - Small of two pieces, Xenogears

My big gripes:

* All options must scale enough to support a monolithic 400-project,=20
  5,000,000-line solution.

This means things like "auto-complete" and "show arguments" as well as=20
"open solution" or "start re-build". It also means no arbitrary limits=20
to number of files in project, number of files in solution, size of=20
object or debug information files, etc. Some of these were made better=20
in VC7, I grant you, but it ain't done yet.

* All settings files need to be text-only, using liberal line feeds, so=20
  they can be easily stored and managed and diffed in source control,=20
  and/or generated from build setup scripts.

It would be nice if they were actually documented, even, but moving=20
away from binary settings files is certainly the first step. We can=20
keep reverse engineering the text files for now :-)

A few small gripes:

* Open Selected doesn't work.

If I select an include in a source file, and use "open selected," I=20
expect the file to be found and opened just like the compiler would=20
find and open it when seeing the same include. Usually, I either get=20
an error about "WBCommand not available" (very paraphrased, I don't=20
have it easily available right now) or a "file not found" error.

* Is there a key for go-to-next-Find-In-All-Files-match ?

I haven't found it. I don't like reaching for the mouse just to=20
navigate my Find results. "Go to next task" does not do it; it only=20
seems to work for compile errors etc.

* Allow copying TEXT out of any window. Compiler errors, disassembly,=20
  memory dumps, project settings windows, whatever.

* Remote serial or IEEE 1394 kernel level debugging, a la WinDbg.=20
  (OK, I can dream, can't I? :-)

* Re-sizable properties/settings pages, text boxes, lists, etc.
  I use Large Fonts. I enter lots of options. The dialogs are very=20
  small.

* Why doesn't IntelliSense work for OpenGL header files?

Cheers,

				/ h+

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> David Notario
> Sent: Thursday, June 12, 2003 1:05 PM
> To: gam...@li...
> Subject: RE: [GD-Windows] VC++ lag
>=20
>=20
> If you guys can provide a list things where vs can improve (from its
> latest version), with arguments such as (X sucks because this, this =
and
> that. Blah doesn't work in this situation), I'll be happy to forward
> your list of petitions to the VS team.
>=20
> David

I would say the default setting is wrong. I was pretty annoyed by that
one too (specially when you use a source control that doesn't integrate
with vs)

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
Rich
Sent: Friday, June 13, 2003 8:15 AM
To: gam...@li...
Subject: Re: [GD-Windows] VC++ lag=20

In article <009401c3318e$72581c80$0301a8c0@pc350>,
    "Colin Fahey" <cp...@ea...>  writes:

> [1] I guess this will only ever happen to any person
> once, but it sure is shocking: =20
>=20
>     Deleting files from the project deletes the source
>     files themselves!

This doesn't happen with all projects all the time.  It depends on how
the files are included in the project.  It is documented under Visual
Studio .NET / Developing with Visual Studio .NET / Managing Solutions,
Projects, and Files / Solutions as Containers / Projects as Containers
/ Item Management in Projects.

You do read the documentation on a new product before you start using
it, don't you? ;-)
--=20
"The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ:
          <http://www.xmission.com/~legalize/book/>
        izfree: Open source tools for Windows Installer
                <http://izfree.sourceforge.net>

-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=3D555

In article <001d01c331b6$36c64c00$0100a8c0@r0x0rz>,
    "Neil Stewart" <ne...@r0...>  writes:

> For some reason, they have changed the functionality of vector::clear() to
> actually deallocate memory, rather than simply doing erase(begin(), end()),
> which leaves the memory allocated.

It sounds to me like you were relying on an implementation dependency.
My copy of "C++ Standard Library" by Josuttis just says that both of
these will remove all the elements of the vector.  AFAIK, the standard
makes no requirements about allocation/deallocation behavior for these
operations, but I would expect both to potentially deallocate memory
when I delete the whole vector.  If you want to clear the vector
without changing its allocation, you should do vector::resize(0) IMO.
-- 
"The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ:
          <http://www.xmission.com/~legalize/book/>
        izfree: Open source tools for Windows Installer
                <http://izfree.sourceforge.net>

In article <009401c3318e$72581c80$0301a8c0@pc350>,
    "Colin Fahey" <cp...@ea...>  writes:

> [1] I guess this will only ever happen to any person
> once, but it sure is shocking:  
> 
>     Deleting files from the project deletes the source
>     files themselves!

This doesn't happen with all projects all the time.  It depends on how
the files are included in the project.  It is documented under Visual
Studio .NET / Developing with Visual Studio .NET / Managing Solutions,
Projects, and Files / Solutions as Containers / Projects as Containers
/ Item Management in Projects.

You do read the documentation on a new product before you start using
it, don't you? ;-)
-- 
"The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ:
          <http://www.xmission.com/~legalize/book/>
        izfree: Open source tools for Windows Installer
                <http://izfree.sourceforge.net>

2001	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep (48)	Oct (58)	Nov (49)	Dec (38)
2002	Jan (124)	Feb (83)	Mar (17)	Apr (37)	May (12)	Jun (20)	Jul (47)	Aug (74)	Sep (62)	Oct (72)	Nov (54)	Dec (13)
2003	Jan (36)	Feb (8)	Mar (38)	Apr (3)	May (6)	Jun (133)	Jul (20)	Aug (18)	Sep (12)	Oct (4)	Nov (28)	Dec (36)
2004	Jan (22)	Feb (51)	Mar (28)	Apr (9)	May (20)	Jun (9)	Jul (37)	Aug (20)	Sep (23)	Oct (15)	Nov (23)	Dec (27)
2005	Jan (22)	Feb (20)	Mar (5)	Apr (14)	May (10)	Jun	Jul (6)	Aug (6)	Sep	Oct (12)	Nov (1)	Dec
2006	Jan (18)	Feb (4)	Mar (3)	Apr (6)	May (4)	Jun (3)	Jul (16)	Aug (40)	Sep (6)	Oct (1)	Nov	Dec (2)
2007	Jan (5)	Feb (2)	Mar (4)	Apr (1)	May (13)	Jun	Jul (26)	Aug (3)	Sep (10)	Oct	Nov (4)	Dec (5)
2008	Jan (1)	Feb	Mar (4)	Apr	May	Jun (5)	Jul	Aug	Sep	Oct	Nov	Dec
2011	Jan	Feb	Mar	Apr	May (1)	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2015	Jan	Feb (3)	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

gamedevlists-windows Mailing List for gamedev (Page 30)

gamedevlists-windows — List for discussing game development on the Windows platform