dev-cpp-users — Dev-C++ users discussion list

Re: [Dev-C++] GCC 3.2 (MinGW 2.0) Compiled File Sizes

[Daniel K. O. <dan...@ya...>]

Marc Heiligers wrote:

> So does anyone know of a way to reduce the file sizes generated by GCC 3.2?


Try:

Switches: -s -Os

And:
strip -s <exename>
upx -9 <exename>


("strip.exe" should be on your mingw bin dir, and UPX you can find on 
SourceForge)

I have them both on my Tools menu.
The C++ hello world now is 71.5 KB :)


g++ is not toooo bloated, I compiled some big (well... not toooo big, 
but bigger than a hello world... 15~20K lines :P ) projetcts, and the 
size (with -O2 switch, and no strip/upx) is usually less than 100 KB 
bigger than the binaries compiled with VC++ (dunno what version). It 
seems acceptable to me. :)




Daniel K. O.

Re: [Dev-C++] GCC 3.2 (MinGW 2.0) Compiled File Sizes

[<or...@vp...>]

Damien X wrote:
> Try adding -s to the commands when calling the compiler.  The older 
> version of Dev-C++ did that by default, making the size of your .exe 
> files small.

And also you might try the -O3 or -O4 flag. Optimization also tends to 
make the exe file smaller.
If you are still not satisfied, head on to:
http://upx.sf.net
,the Ultimate Packer for eXecutables homepage. It does it's job very 
well, even better than commercial exe packers.
Copy upx.exe into your path somewhere (so you can use it anywhere), then 
use "upx -9 <filename>" for best compression.

Your program, that was 416 KB, after stripping (-s) and upx-ing, was 
reduced to 73 KB.

--
Greetings,
   Balázs

RE: [Dev-C++] GCC 3.2 (MinGW 2.0) Compiled File Sizes

[Ioannis V. <iv...@em...>]

> -----Original Message-----
> From: dev...@li...=20
> [mailto:dev...@li...] On Behalf=20
> Of Marc Heiligers
> Sent: Saturday, July 12, 2003 8:04 PM
> To: Dev-Cpp User's List
> Subject: [Dev-C++] GCC 3.2 (MinGW 2.0) Compiled File Sizes
>=20
>=20
> I just wrote a command line program that does a little string=20
> manipulation
> and spits out (read as cout << (std::string)) a modified=20
> string (using the
> command line parameters as input). The complete source is=20
> less 100 lines of
> code and resides in a single file. I make use of the=20
> <iostream> and <string>
> headers. I compiled and found it worked perfectly, but the=20
> executable was
> 468KB in size! I was expecting something more along the lines=20
> of 10KB. So I
> tried the following little program:
>=20
> #include <iostream>
> #include <string>
>=20
> int main(int argc, char *argv[])
> {
> 	std::string s =3D "Hello, World";
> 	std::cout << s;
> 	return 0;
> }
>=20
> This simple "Hello, World" demo compiles to 442KB (using=20
> default compiler
> settings, no optimization, no exception handling - and 156KB=20
> using the old
> Dev-Cpp default compiler). This is a little extreme, don't you think?


Yes, g++ has been entirely rewritten and produces more bloated code... I
guess mainly because they use bloated header files (their system =
extensions
must be collected to few header files).


>=20
> So does anyone know of a way to reduce the file sizes=20
> generated by GCC 3.2?


Only the optimisation switches.



> The only thing that springs to mind is that the template=20
> class handling of
> GCC is not that great. If we try the same demo using C-code=20
> (compiled as
> C++):
>=20
> #include <stdio.h>
>=20
> int main(int argc, char *argv[])
> {
> 	char* s =3D "Hello, World";
> 	printf("%s", s);
> 	return 0;
> }
>=20
> we get a program that compiles to 21KB (and 9KB using the old Default
> Dev-Cpp compiler - even this shows a large increase in size=20
> using GCC 3.2)!=20


I think we can be sure that as time passes things will get improving. =
That's
all. :-)






Ioannis Vranos
=20
* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

Re: [Dev-C++] GCC 3.2 (MinGW 2.0) Compiled File Sizes

[Damien <g_...@ho...>]

<html><div style='background-color:'><DIV>
<P>Try adding -s to the commands when calling the compiler.&nbsp; The older version of Dev-C++ did that by default, making the size of your .exe files small.<BR><BR></P></DIV>
<DIV></DIV>----Original Message Follows---- 
<DIV></DIV>From: "Marc Heiligers" <MA...@E-...>
<DIV></DIV>To: "Dev-Cpp User's List" <DEV...@LI...>
<DIV></DIV>Subject: [Dev-C++] GCC 3.2 (MinGW 2.0) Compiled File Sizes 
<DIV></DIV>Date: Sat, 12 Jul 2003 19:03:37 +0200 
<DIV></DIV><mailto:dev...@li...?subject=help><mailto:dev...@li...><mailto:dev...@li...?subject=subscribe><mailto:dev...@li...?subject=unsubscribe>
<DIV></DIV>
<DIV></DIV>Hi All, 
<DIV></DIV>
<DIV></DIV>I have just downloaded and installed MinGW 2.0 to upgrade my development 
<DIV></DIV>environment to the latest (easily available) GCC. The installation process 
<DIV></DIV>was surprisingly painless and getting it to work with Dev-Cpp was just as 
<DIV></DIV>easy. Good stuff so far. But... 
<DIV></DIV>
<DIV></DIV>I just wrote a command line program that does a little string manipulation 
<DIV></DIV>and spits out (read as cout &lt;&lt; (std::string)) a modified string (using the 
<DIV></DIV>command line parameters as input). The complete source is less 100 lines of 
<DIV></DIV>code and resides in a single file. I make use of the <IOSTREAM>and <STRING>
<DIV></DIV>headers. I compiled and found it worked perfectly, but the executable was 
<DIV></DIV>468KB in size! I was expecting something more along the lines of 10KB. So I 
<DIV></DIV>tried the following little program: 
<DIV></DIV>
<DIV></DIV>#include <IOSTREAM>
<DIV></DIV>#include <STRING>
<DIV></DIV>
<DIV></DIV>int main(int argc, char *argv[]) 
<DIV></DIV>{ 
<DIV></DIV>std::string s = "Hello, World"; 
<DIV></DIV>std::cout &lt;&lt; s; 
<DIV></DIV>return 0; 
<DIV></DIV>} 
<DIV></DIV>
<DIV></DIV>This simple "Hello, World" demo compiles to 442KB (using default compiler 
<DIV></DIV>settings, no optimization, no exception handling - and 156KB using the old 
<DIV></DIV>Dev-Cpp default compiler). This is a little extreme, don't you think? 
<DIV></DIV>
<DIV></DIV>So does anyone know of a way to reduce the file sizes generated by GCC 3.2? 
<DIV></DIV>The only thing that springs to mind is that the template class handling of 
<DIV></DIV>GCC is not that great. If we try the same demo using C-code (compiled as 
<DIV></DIV>C++): 
<DIV></DIV>
<DIV></DIV>#include <STDIO.H>
<DIV></DIV>
<DIV></DIV>int main(int argc, char *argv[]) 
<DIV></DIV>{ 
<DIV></DIV>char* s = "Hello, World"; 
<DIV></DIV>printf("%s", s); 
<DIV></DIV>return 0; 
<DIV></DIV>} 
<DIV></DIV>
<DIV></DIV>we get a program that compiles to 21KB (and 9KB using the old Default 
<DIV></DIV>Dev-Cpp compiler - even this shows a large increase in size using GCC 3.2)! 
<DIV></DIV>
<DIV></DIV>Regards, 
<DIV></DIV>Marc. 
<DIV></DIV>
<DIV></DIV>
<DIV></DIV>
<DIV></DIV>------------------------------------------------------- 
<DIV></DIV>This SF.Net email sponsored by: Parasoft 
<DIV></DIV>Error proof Web apps, automate testing &amp; more. 
<DIV></DIV>Download &amp; eval WebKing and get a free book. 
<DIV></DIV>www.parasoft.com/bulletproofapps1 
<DIV></DIV>_______________________________________________ 
<DIV></DIV>Dev-cpp-users mailing list 
<DIV></DIV>Dev...@li... 
<DIV></DIV>TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm 
<DIV></DIV>https://lists.sourceforge.net/lists/listinfo/dev-cpp-users 
<DIV></DIV></mailto:dev...@li...?subject=unsubscribe></mailto:dev...@li...?subject=subscribe></mailto:dev...@li...></mailto:dev...@li...?subject=help></div><br clear=all><hr>MSN 8 with <a href="http://g.msn.com/8HMFEN/2740??PS=">e-mail virus protection service: </a> 2 months FREE*</html>

[Dev-C++] GCC 3.2 (MinGW 2.0) Compiled File Sizes

[Marc H. <ma...@e-...>]

Hi All,

I have just downloaded and installed MinGW 2.0 to upgrade my development
environment to the latest (easily available) GCC. The installation =
process
was surprisingly painless and getting it to work with Dev-Cpp was just =
as
easy. Good stuff so far. But...

I just wrote a command line program that does a little string =
manipulation
and spits out (read as cout << (std::string)) a modified string (using =
the
command line parameters as input). The complete source is less 100 lines =
of
code and resides in a single file. I make use of the <iostream> and =
<string>
headers. I compiled and found it worked perfectly, but the executable =
was
468KB in size! I was expecting something more along the lines of 10KB. =
So I
tried the following little program:

#include <iostream>
#include <string>

int main(int argc, char *argv[])
{
	std::string s =3D "Hello, World";
	std::cout << s;
	return 0;
}

This simple "Hello, World" demo compiles to 442KB (using default =
compiler
settings, no optimization, no exception handling - and 156KB using the =
old
Dev-Cpp default compiler). This is a little extreme, don't you think?

So does anyone know of a way to reduce the file sizes generated by GCC =
3.2?
The only thing that springs to mind is that the template class handling =
of
GCC is not that great. If we try the same demo using C-code (compiled as
C++):

#include <stdio.h>

int main(int argc, char *argv[])
{
	char* s =3D "Hello, World";
	printf("%s", s);
	return 0;
}

we get a program that compiles to 21KB (and 9KB using the old Default
Dev-Cpp compiler - even this shows a large increase in size using GCC =
3.2)!=20

Regards,
Marc.

Re: [Dev-C++] library pdh.lib

[<or...@vp...>]

Paulo Moura Guedes wrote:
> I tried to link my program with pdh.lib and the result was:
> “
> ../../../../../Programas/Borland/BCC55/Lib/PSDK/pdh.lib: file not 
> recognized: File format not recognized
> “
> 
> Can somebody help me?

Yes, it is simple: the file format of the library is not recognised. I 
don't know if GCC can use Borland libraries for linking...

--
Greetings,
   Balázs

RE: [Dev-C++] STL Map question

[Ioannis V. <iv...@em...>]

Here is what I said in a similar discussion in Usenet, it may help:


"Sandeep Grover" <sa...@ma...> wrote in message
news:3F0...@ma......
> Hi,
>
> If I do another delete on an object which has been deleted earlier, =
then
> how is
> the system expected to behave ?


It will get angry.



> Is it an unpredictable behavior ??


Yes it is undefined behaviour. It may die, it may continue living and =
die
later, it may truncate data, everything.







--=20
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net


-------------------------------------------------------------------------=
---
-----------------------



"Sandeep Grover" <sa...@ma...> wrote in message
news:3F0...@ma......
>
>
> > Sandeep Grover wrote:
> >
> > > If I do another delete on an object which has been deleted =
earlier,
then
> > > how is the system expected to behave?
> > >
> > > Is it an unpredictable behavior ??
> >
> > It's undefined, so in theory, yes; anything could happen.
> >
> > S
>
> Thanks !
>
> So, if I have an array of pointers; more than one of the entries could
point
> to
> the same chunk of memory (allocated using new). How do I ensure that I
> end up deleting that entry only once. I dont want to use
reference-counting
> kind of thing in constructor.


Use a vector of the objects you want, or a list if it suits better the
problem, and not a built in array of pointers.







--=20
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

RE: [Dev-C++] STL Map question

[Ioannis V. <iv...@em...>]

> -----Original Message-----
> From: Per Westermark [mailto:pw...@ia...] 
> Sent: Saturday, July 12, 2003 2:04 AM
> To: Ioannis Vranos
> Cc: Dev-C++ Mailing List
> Subject: RE: [Dev-C++] STL Map question
> 
> 
> Ioannis:
> For older compilers, new doesn't throw an exception. Depending on
> configuration and/or implementation, they either return NULL, call an
> installable callback function or kill the program.



I never talk about legacy stuff. :-) I assume a modern compiler and in
particular I assumed Dev-C++.



 
> The implementation of user handling might be absolutely bug-free. It
> doesn't help if some other part of the program somehow goofs up and
> somehow overwrites memory.


Yes.


 
> A dual delete on an object somewhere in the program is a 
> perfect example
> of how a program without any strange pointer manipulation 
> might perform
> memory overwrites, by destroying the heap.



Yes, but without being required by the standard, most probably the program
would die directly upon the second deletion.



In any case we can make only assumptions without the code. And we can also
make observations. And I had observed old stuff, char *s, strcmp()s. As I
had pointed out in a previous email, replacing all char *s with std::string
is a good starting point.






Ioannis Vranos
 
* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

RE: [Dev-C++] STL Map question

[Per W. <pw...@ia...>]

Ioannis:
For older compilers, new doesn't throw an exception. Depending on
configuration and/or implementation, they either return NULL, call an
installable callback function or kill the program.

The implementation of user handling might be absolutely bug-free. It
doesn't help if some other part of the program somehow goofs up and
somehow overwrites memory.

A dual delete on an object somewhere in the program is a perfect example
of how a program without any strange pointer manipulation might perform
memory overwrites, by destroying the heap.

Shane: Have you tried some heap-debugging code, that checks the following
for every memory release:
- that it is a validly allocated pointer
- that the memory hasn't already been released
- that guard bytes of the block hasn't been overwritten.

/Per W

On Sat, 12 Jul 2003, Ioannis Vranos wrote:

> > -----Original Message-----
> > From: dev...@li...
> > [mailto:dev...@li...] On Behalf
> > Of Shane Bryldt
> > Sent: Friday, July 11, 2003 11:53 PM
> > To: Hossein Haeri
> > Cc: C++
> > Subject: Re: [Dev-C++] STL Map question
> >
> >
> > Actually, since I had about 20 responses on this topic, none of which
> > actually got close to the effect, nevermind the cause of the
> > problem, I will
> > try and explain the situation in more detail.  However, to
> > make the records
> > clear, I don't expect to find an answer now.  I have looked
> > the code over a
> > number of times, and had another expert which is admittedly
> > significantly
> > better with C++ and STL than myself, and even he cannot seem
> > to find any
> > problems which relate.  Given old working code, and my new
> > adjusted code,
> > many changes were made but I cannot determine what is causing
> > the problem.
> >
> > Now, the effect of the issue, is as follows. A network of 6,000-10,000
> > active users at any given time is regulated by a security
> > service.  This
> > service runs and connects like a user, with special
> > priviledges.  Anytime a
> > user connects to the network, the services is informed, and
> > the User is
> > added to a global UserList.  The network also has smaller
> > units, known as
> > Channels.  Each Channel contains 3 UserList's as well.
> > First, depicts all
> > users in the Channel, the second depicts all the operators of
> > the channel,
> > and the third depicts the priviledged users who are not
> > operators.  99% of
> > the time, the code work fine.  Users constantly added and
> > removed from the
> > list.  Periodically, what seems like an issue without a
> > pattern, the code
> > will crash with a segmentation fault while trying to call
> > "std::map<>::find()", with a valid key.  Whether the key is
> > in the map, is
> > not definate, but the key passed in valid and should not have
> > a problem
> > being searched.
> >
> > This said, I have narrowed the issue down to one of 2 causes.
> > 1) Either
> > User's are being added to lists, and not being removed, and
> > the UserLists
> > are eventually gathering enough garbage that out of memory is being
> > encountered.
>
>
> In this case if you use the operator new as you should, an std::bad_alloc()
> exception would be thrown (defined in <new>) and as you should you must have
> at least a catch(std::bad_allloc) in main() to catch such exceptions and at
> least make the problem known by displaying an error message and shutting
> down the program properly).
>
>
>
>
> > The application has a signal hook for out of
> > memory, and it is
> > not being raised.
>
>
> Let's hope you mean a catch clause.
>
>
>
> > So I am leaning more towards option 2) The
> > User class is
> > being deleted, without being removed from the UserList.
> > However, I can find
> > no indication of this in the code.  The code is many
> > thousands of lines, it
> > is not a small project by any means.  Providing the source
> > for the issue,
> > would require the entire project as the issue is not
> > specifically a syntax
> > issue, but rather a situational issue.  I do believe something has
> > invalidated a User class, which a UserList has a pointer to,
> > and when trying
> > to use it, is causing a segmentation fault.  I'm sure most of
> > the experts
> > here will agree with my conclusion and realize tracing this
> > problem is no
> > easy task.
>
>
> We must see at least the entire definitions of UserList and User. Can you
> provide them?
>
>
>
> > I've considered some commercial products like Purify, or some
> > other memory
> > tracking products, but I have no experience with any, since
> > I've never had
> > an issue I couldn't resolve purely with GDB.  Since the
> > problem traces back
> > most likely to an invalid pointer reference, does anyone have
> > suggestions on
> > how I could possibly detect where the pointer is being deleted?
>
>
>
> I am not an expert, I am still learning (and unfortunately there is an
> infinite number of things that I want to learn) but I think that if there
> has been a more proper use of C++, the code would have been more bullet
> proof. That is using the superior alternatives that C++ provides instead of
> the old stuff that they exist to replace.
>
>
>
>
> >  I've
> > considered the idea of using smart pointers to track the
> > issue down, but
> > again I'm not entirely certain of how to implement some code
> > to track where
> > the User is being deleted without being removed from the
> > channels they are
> > in... It could also potentially be an issue with overwritting
> > memory, but
> > with how often it is caused in exactly the same way, it's
> > unlikely to be
> > memory overbounding.
> > I noticed a location where the key being used was being changed (a
> > nickname), and in those cases, where the old code would just
> > rename the
> > nickname, I have now remove from the map and then readd to
> > the map. When it
> > tries to remove from the map is when it crashes.  I can only
> > assume that the
> > problem is an invalid pointer, thus the map::find function is crashing
> > because of invalid memory.  The key was based on a const char
> > *, but the
> > other expert I consulted suggested using std::string to help track the
> > problem until it is found... Changing to use std::string is
> > how I determined
> > that the key was still valid (because it had a copy of the
> > nick instead of a
> > pointer to the nick which may be invalidated at some point),
> > and the key was
> > still intact as far as I can remember, the pointer however
> > caused GDB itself
> > to indicate that the program crashed again from a call by
> > GDB, when trying
> > to access a member of the pointer.
> >
> >
> > Okay, hopefully these details will clarify for all the people
> > who tried to
> > help... The problem itself is not something so simple as was
> > suggested so
> > far.  However, Hossein did make one point that I should have realized
> > myself.  Not that it matters, but I should use empty()
> > instead of size() ==
> > 0, since it's possible empty() can execute faster than
> > size().
>
>
> Eh? Why? Both have the same speed, actually empty is usually
>
> // inside the class definition
> bool empty() const {  return size()==0; }
>
>
> since map has to keep track of its size. In any case consider them as equal
> (an equality comparison doesn't take time!).
>
>
>
> >  But speaking
> > from the ANSI compliance, size() == 0 is identical to empty()
> > == true in
> > result, just not exection.  That said, it will not affect the problem.
>
>
> Yeap. Please provide us with the complete defintions of User and UserList.
> :-)
>
>
>
>
>
>
> Ioannis Vranos
>
> * Programming pages: http://www.noicys.freeurl.com
> * Alternative URL 1: http://run.to/noicys
> * Alternative URL 2: http://www.noicys.cjb.net
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Parasoft
> Error proof Web apps, automate testing & more.
> Download & eval WebKing and get a free book.
> www.parasoft.com/bulletproofapps1
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>

RE: [Dev-C++] STL Map question

[Ioannis V. <iv...@em...>]

> -----Original Message-----
> From: dev...@li...=20
> [mailto:dev...@li...] On Behalf=20
> Of Shane Bryldt
> Sent: Friday, July 11, 2003 11:53 PM
> To: Hossein Haeri
> Cc: C++
> Subject: Re: [Dev-C++] STL Map question
>=20
>=20
> Actually, since I had about 20 responses on this topic, none of which
> actually got close to the effect, nevermind the cause of the=20
> problem, I will
> try and explain the situation in more detail.  However, to=20
> make the records
> clear, I don't expect to find an answer now.  I have looked=20
> the code over a
> number of times, and had another expert which is admittedly=20
> significantly
> better with C++ and STL than myself, and even he cannot seem=20
> to find any
> problems which relate.  Given old working code, and my new=20
> adjusted code,
> many changes were made but I cannot determine what is causing=20
> the problem.
>=20
> Now, the effect of the issue, is as follows. A network of 6,000-10,000
> active users at any given time is regulated by a security=20
> service.  This
> service runs and connects like a user, with special=20
> priviledges.  Anytime a
> user connects to the network, the services is informed, and=20
> the User is
> added to a global UserList.  The network also has smaller=20
> units, known as
> Channels.  Each Channel contains 3 UserList's as well. =20
> First, depicts all
> users in the Channel, the second depicts all the operators of=20
> the channel,
> and the third depicts the priviledged users who are not=20
> operators.  99% of
> the time, the code work fine.  Users constantly added and=20
> removed from the
> list.  Periodically, what seems like an issue without a=20
> pattern, the code
> will crash with a segmentation fault while trying to call
> "std::map<>::find()", with a valid key.  Whether the key is=20
> in the map, is
> not definate, but the key passed in valid and should not have=20
> a problem
> being searched.
>=20
> This said, I have narrowed the issue down to one of 2 causes.=20
> 1) Either
> User's are being added to lists, and not being removed, and=20
> the UserLists
> are eventually gathering enough garbage that out of memory is being
> encountered.


In this case if you use the operator new as you should, an =
std::bad_alloc()
exception would be thrown (defined in <new>) and as you should you must =
have
at least a catch(std::bad_allloc) in main() to catch such exceptions and =
at
least make the problem known by displaying an error message and shutting
down the program properly).




> The application has a signal hook for out of=20
> memory, and it is
> not being raised.=20


Let's hope you mean a catch clause.



> So I am leaning more towards option 2) The=20
> User class is
> being deleted, without being removed from the UserList. =20
> However, I can find
> no indication of this in the code.  The code is many=20
> thousands of lines, it
> is not a small project by any means.  Providing the source=20
> for the issue,
> would require the entire project as the issue is not=20
> specifically a syntax
> issue, but rather a situational issue.  I do believe something has
> invalidated a User class, which a UserList has a pointer to,=20
> and when trying
> to use it, is causing a segmentation fault.  I'm sure most of=20
> the experts
> here will agree with my conclusion and realize tracing this=20
> problem is no
> easy task.


We must see at least the entire definitions of UserList and User. Can =
you
provide them?


=20
> I've considered some commercial products like Purify, or some=20
> other memory
> tracking products, but I have no experience with any, since=20
> I've never had
> an issue I couldn't resolve purely with GDB.  Since the=20
> problem traces back
> most likely to an invalid pointer reference, does anyone have=20
> suggestions on
> how I could possibly detect where the pointer is being deleted?



I am not an expert, I am still learning (and unfortunately there is an
infinite number of things that I want to learn) but I think that if =
there
has been a more proper use of C++, the code would have been more bullet
proof. That is using the superior alternatives that C++ provides instead =
of
the old stuff that they exist to replace.




>  I've
> considered the idea of using smart pointers to track the=20
> issue down, but
> again I'm not entirely certain of how to implement some code=20
> to track where
> the User is being deleted without being removed from the=20
> channels they are
> in... It could also potentially be an issue with overwritting=20
> memory, but
> with how often it is caused in exactly the same way, it's=20
> unlikely to be
> memory overbounding.
> I noticed a location where the key being used was being changed (a
> nickname), and in those cases, where the old code would just=20
> rename the
> nickname, I have now remove from the map and then readd to=20
> the map. When it
> tries to remove from the map is when it crashes.  I can only=20
> assume that the
> problem is an invalid pointer, thus the map::find function is crashing
> because of invalid memory.  The key was based on a const char=20
> *, but the
> other expert I consulted suggested using std::string to help track the
> problem until it is found... Changing to use std::string is=20
> how I determined
> that the key was still valid (because it had a copy of the=20
> nick instead of a
> pointer to the nick which may be invalidated at some point),=20
> and the key was
> still intact as far as I can remember, the pointer however=20
> caused GDB itself
> to indicate that the program crashed again from a call by=20
> GDB, when trying
> to access a member of the pointer.
>=20
>=20
> Okay, hopefully these details will clarify for all the people=20
> who tried to
> help... The problem itself is not something so simple as was=20
> suggested so
> far.  However, Hossein did make one point that I should have realized
> myself.  Not that it matters, but I should use empty()=20
> instead of size() =3D=3D
> 0, since it's possible empty() can execute faster than=20
> size().


Eh? Why? Both have the same speed, actually empty is usually=20

// inside the class definition
bool empty() const {  return size()=3D=3D0; }


since map has to keep track of its size. In any case consider them as =
equal
(an equality comparison doesn't take time!).



>  But speaking
> from the ANSI compliance, size() =3D=3D 0 is identical to empty()=20
> =3D=3D true in
> result, just not exection.  That said, it will not affect the problem.


Yeap. Please provide us with the complete defintions of User and =
UserList.
:-)






Ioannis Vranos
=20
* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

[Dev-C++] library pdh.lib

[Paulo M. G. <pm...@ne...>]

I tried to link my program with pdh.lib and the result was:
"
../../../../../Programas/Borland/BCC55/Lib/PSDK/pdh.lib: file not
recognized: File format not recognized
"
 
Can somebody help me?
 
Thank's
Paulo

Re: [Dev-C++] need help!

[Shane B. <ast...@te...>]

I was sorta curious about this myself.  I can be hostile at times, so people
often accuse me of trying to start flaming wars, but when I read this post,
I felt no hostility or sarcasm at all...  Whoever it was that thought this
was hostile, you need to learn how to read English, because there was no
personal feelings involved in the post, it was purely informational... That
said, purely informational posts which address specific questions are hard
to find, don't complain when the answer is clear.

    -Shane

----- Original Message ----- 
From: "Per Westermark" <pw...@ia...>
To: "OROSZI Balázs" <or...@vp...>
Cc: <dev...@li...>
Sent: Friday, July 11, 2003 2:53 PM
Subject: Re: [Dev-C++] need help!


I have deleted the original question and Adam's answer, so I can't check
the full-text messages.

However, where in Adam's response did you see any "heavy" sarcasms? The
citated part does mention FindFirst/FindNext/... and the very valid remark
that FindClose() must be used.

It is a very, very common mistake to forget the FindClose(), since since
the program would leak handles and memory resources without the call -
resulting in future failures if the directory scan is performed multiple
times without restart of the application.

/Per W

On Fri, 11 Jul 2003, [ISO-8859-2] OROSZI Balázs wrote:

> Adam Malinowski wrote:
> >>I am new to C++. I like to read files name in the folder . For an
example,
> >>My path is "C:\temp\data ", and in the folder there are some files that
i
> >>need to read only file name like file1.dat , file2.dat , file3.dat ....
> >
> > all
> >
> >>my dat file. If anyone have any advice or good idea how to write this
> >>function for me I will be very happy. Thank you very much
> >>
> >
> > Try FindFirst and FindNext or FindFirstFile and FindNextFile.
> > You can specify diiferent parameters and file extension is one of them.
> >
> > FindFirst and aFindNext belongs to VCL library.
> > FindFirstFile and FindNextFile are Win32 API functions.
> >
> > Remember to use FindClose.
>
> Don't you think this was a bit "strong" or "heavy" for sarcasm?
>
> --
> Greetings,
>    Balázs
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Parasoft
> Error proof Web apps, automate testing & more.
> Download & eval WebKing and get a free book.
> www.parasoft.com/bulletproofapps1
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>



-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1
_______________________________________________
Dev-cpp-users mailing list
Dev...@li...
TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
https://lists.sourceforge.net/lists/listinfo/dev-cpp-users

Re: [Dev-C++] need help!

[Shane B. <ast...@te...>]

I was sorta curious about this myself.  I can be hostile at times, so people
often accuse me of trying to start flaming wars, but when I read this post,
I felt no hostility or sarcasm at all...  Whoever it was that thought this
was hostile, you need to learn how to read English, because there was no
personal feelings involved in the post, it was purely informational... That
said, purely informational posts which address specific questions are hard
to find, don't complain when the answer is clear.

    -Shane

----- Original Message ----- 
From: "Per Westermark" <pw...@ia...>
To: "OROSZI Balázs" <or...@vp...>
Cc: <dev...@li...>
Sent: Friday, July 11, 2003 2:53 PM
Subject: Re: [Dev-C++] need help!


I have deleted the original question and Adam's answer, so I can't check
the full-text messages.

However, where in Adam's response did you see any "heavy" sarcasms? The
citated part does mention FindFirst/FindNext/... and the very valid remark
that FindClose() must be used.

It is a very, very common mistake to forget the FindClose(), since since
the program would leak handles and memory resources without the call -
resulting in future failures if the directory scan is performed multiple
times without restart of the application.

/Per W

On Fri, 11 Jul 2003, [ISO-8859-2] OROSZI Balázs wrote:

> Adam Malinowski wrote:
> >>I am new to C++. I like to read files name in the folder . For an
example,
> >>My path is "C:\temp\data ", and in the folder there are some files that
i
> >>need to read only file name like file1.dat , file2.dat , file3.dat ....
> >
> > all
> >
> >>my dat file. If anyone have any advice or good idea how to write this
> >>function for me I will be very happy. Thank you very much
> >>
> >
> > Try FindFirst and FindNext or FindFirstFile and FindNextFile.
> > You can specify diiferent parameters and file extension is one of them.
> >
> > FindFirst and aFindNext belongs to VCL library.
> > FindFirstFile and FindNextFile are Win32 API functions.
> >
> > Remember to use FindClose.
>
> Don't you think this was a bit "strong" or "heavy" for sarcasm?
>
> --
> Greetings,
>    Balázs
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Parasoft
> Error proof Web apps, automate testing & more.
> Download & eval WebKing and get a free book.
> www.parasoft.com/bulletproofapps1
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>



-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1
_______________________________________________
Dev-cpp-users mailing list
Dev...@li...
TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
https://lists.sourceforge.net/lists/listinfo/dev-cpp-users

Re: [Dev-C++] STL Map question

[Shane B. <ast...@te...>]

Actually, since I had about 20 responses on this topic, none of which
actually got close to the effect, nevermind the cause of the problem, I will
try and explain the situation in more detail.  However, to make the records
clear, I don't expect to find an answer now.  I have looked the code over a
number of times, and had another expert which is admittedly significantly
better with C++ and STL than myself, and even he cannot seem to find any
problems which relate.  Given old working code, and my new adjusted code,
many changes were made but I cannot determine what is causing the problem.

Now, the effect of the issue, is as follows. A network of 6,000-10,000
active users at any given time is regulated by a security service.  This
service runs and connects like a user, with special priviledges.  Anytime a
user connects to the network, the services is informed, and the User is
added to a global UserList.  The network also has smaller units, known as
Channels.  Each Channel contains 3 UserList's as well.  First, depicts all
users in the Channel, the second depicts all the operators of the channel,
and the third depicts the priviledged users who are not operators.  99% of
the time, the code work fine.  Users constantly added and removed from the
list.  Periodically, what seems like an issue without a pattern, the code
will crash with a segmentation fault while trying to call
"std::map<>::find()", with a valid key.  Whether the key is in the map, is
not definate, but the key passed in valid and should not have a problem
being searched.

This said, I have narrowed the issue down to one of 2 causes. 1) Either
User's are being added to lists, and not being removed, and the UserLists
are eventually gathering enough garbage that out of memory is being
encountered. The application has a signal hook for out of memory, and it is
not being raised.  So I am leaning more towards option 2) The User class is
being deleted, without being removed from the UserList.  However, I can find
no indication of this in the code.  The code is many thousands of lines, it
is not a small project by any means.  Providing the source for the issue,
would require the entire project as the issue is not specifically a syntax
issue, but rather a situational issue.  I do believe something has
invalidated a User class, which a UserList has a pointer to, and when trying
to use it, is causing a segmentation fault.  I'm sure most of the experts
here will agree with my conclusion and realize tracing this problem is no
easy task.

I've considered some commercial products like Purify, or some other memory
tracking products, but I have no experience with any, since I've never had
an issue I couldn't resolve purely with GDB.  Since the problem traces back
most likely to an invalid pointer reference, does anyone have suggestions on
how I could possibly detect where the pointer is being deleted?  I've
considered the idea of using smart pointers to track the issue down, but
again I'm not entirely certain of how to implement some code to track where
the User is being deleted without being removed from the channels they are
in... It could also potentially be an issue with overwritting memory, but
with how often it is caused in exactly the same way, it's unlikely to be
memory overbounding.
I noticed a location where the key being used was being changed (a
nickname), and in those cases, where the old code would just rename the
nickname, I have now remove from the map and then readd to the map. When it
tries to remove from the map is when it crashes.  I can only assume that the
problem is an invalid pointer, thus the map::find function is crashing
because of invalid memory.  The key was based on a const char *, but the
other expert I consulted suggested using std::string to help track the
problem until it is found... Changing to use std::string is how I determined
that the key was still valid (because it had a copy of the nick instead of a
pointer to the nick which may be invalidated at some point), and the key was
still intact as far as I can remember, the pointer however caused GDB itself
to indicate that the program crashed again from a call by GDB, when trying
to access a member of the pointer.


Okay, hopefully these details will clarify for all the people who tried to
help... The problem itself is not something so simple as was suggested so
far.  However, Hossein did make one point that I should have realized
myself.  Not that it matters, but I should use empty() instead of size() ==
0, since it's possible empty() can execute faster than size().  But speaking
from the ANSI compliance, size() == 0 is identical to empty() == true in
result, just not exection.  That said, it will not affect the problem.

    -Shane
----- Original Message ----- 
From: "Hossein Haeri" <ult...@em...>
To: <dev...@li...>
Sent: Friday, July 11, 2003 5:19 AM
Subject: RE: [Dev-C++] STL Map question


> I'm not sure if it helps, but just try (!map<>::empty()) instead of
> (map<>::size() > 0) to see what happens!
>
> Sorry if it seems a little off-topic. But that's because I still
> couldn't realise what had caused the bug. I'm trying to check if there
> is any bug in your C++ implementation's std::map<>. Maybe,
> map<>::size() does something causing pointer invalidation!
>
> Let me know the result!
>
> Regards,
> --Hossein
> -- 
> __________________________________________________________
> Sign-up for your own FREE Personalized E-mail at Mail.com
> http://www.mail.com/?sr=signup
>
> CareerBuilder.com has over 400,000 jobs. Be smarter about your job search
> http://corp.mail.com/careers
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Parasoft
> Error proof Web apps, automate testing & more.
> Download & eval WebKing and get a free book.
> www.parasoft.com/bulletproofapps1
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>

Re: [Dev-C++] STL Map question

[Shane B. <ast...@te...>]

Actually, since I had about 20 responses on this topic, none of which
actually got close to the effect, nevermind the cause of the problem, I will
try and explain the situation in more detail.  However, to make the records
clear, I don't expect to find an answer now.  I have looked the code over a
number of times, and had another expert which is admittedly significantly
better with C++ and STL than myself, and even he cannot seem to find any
problems which relate.  Given old working code, and my new adjusted code,
many changes were made but I cannot determine what is causing the problem.

Now, the effect of the issue, is as follows. A network of 6,000-10,000
active users at any given time is regulated by a security service.  This
service runs and connects like a user, with special priviledges.  Anytime a
user connects to the network, the services is informed, and the User is
added to a global UserList.  The network also has smaller units, known as
Channels.  Each Channel contains 3 UserList's as well.  First, depicts all
users in the Channel, the second depicts all the operators of the channel,
and the third depicts the priviledged users who are not operators.  99% of
the time, the code work fine.  Users constantly added and removed from the
list.  Periodically, what seems like an issue without a pattern, the code
will crash with a segmentation fault while trying to call
"std::map<>::find()", with a valid key.  Whether the key is in the map, is
not definate, but the key passed in valid and should not have a problem
being searched.

This said, I have narrowed the issue down to one of 2 causes. 1) Either
User's are being added to lists, and not being removed, and the UserLists
are eventually gathering enough garbage that out of memory is being
encountered. The application has a signal hook for out of memory, and it is
not being raised.  So I am leaning more towards option 2) The User class is
being deleted, without being removed from the UserList.  However, I can find
no indication of this in the code.  The code is many thousands of lines, it
is not a small project by any means.  Providing the source for the issue,
would require the entire project as the issue is not specifically a syntax
issue, but rather a situational issue.  I do believe something has
invalidated a User class, which a UserList has a pointer to, and when trying
to use it, is causing a segmentation fault.  I'm sure most of the experts
here will agree with my conclusion and realize tracing this problem is no
easy task.

I've considered some commercial products like Purify, or some other memory
tracking products, but I have no experience with any, since I've never had
an issue I couldn't resolve purely with GDB.  Since the problem traces back
most likely to an invalid pointer reference, does anyone have suggestions on
how I could possibly detect where the pointer is being deleted?  I've
considered the idea of using smart pointers to track the issue down, but
again I'm not entirely certain of how to implement some code to track where
the User is being deleted without being removed from the channels they are
in... It could also potentially be an issue with overwritting memory, but
with how often it is caused in exactly the same way, it's unlikely to be
memory overbounding.
I noticed a location where the key being used was being changed (a
nickname), and in those cases, where the old code would just rename the
nickname, I have now remove from the map and then readd to the map. When it
tries to remove from the map is when it crashes.  I can only assume that the
problem is an invalid pointer, thus the map::find function is crashing
because of invalid memory.  The key was based on a const char *, but the
other expert I consulted suggested using std::string to help track the
problem until it is found... Changing to use std::string is how I determined
that the key was still valid (because it had a copy of the nick instead of a
pointer to the nick which may be invalidated at some point), and the key was
still intact as far as I can remember, the pointer however caused GDB itself
to indicate that the program crashed again from a call by GDB, when trying
to access a member of the pointer.


Okay, hopefully these details will clarify for all the people who tried to
help... The problem itself is not something so simple as was suggested so
far.  However, Hossein did make one point that I should have realized
myself.  Not that it matters, but I should use empty() instead of size() ==
0, since it's possible empty() can execute faster than size().  But speaking
from the ANSI compliance, size() == 0 is identical to empty() == true in
result, just not exection.  That said, it will not affect the problem.

    -Shane
----- Original Message ----- 
From: "Hossein Haeri" <ult...@em...>
To: <dev...@li...>
Sent: Friday, July 11, 2003 5:19 AM
Subject: RE: [Dev-C++] STL Map question


> I'm not sure if it helps, but just try (!map<>::empty()) instead of
> (map<>::size() > 0) to see what happens!
>
> Sorry if it seems a little off-topic. But that's because I still
> couldn't realise what had caused the bug. I'm trying to check if there
> is any bug in your C++ implementation's std::map<>. Maybe,
> map<>::size() does something causing pointer invalidation!
>
> Let me know the result!
>
> Regards,
> --Hossein
> -- 
> __________________________________________________________
> Sign-up for your own FREE Personalized E-mail at Mail.com
> http://www.mail.com/?sr=signup
>
> CareerBuilder.com has over 400,000 jobs. Be smarter about your job search
> http://corp.mail.com/careers
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Parasoft
> Error proof Web apps, automate testing & more.
> Download & eval WebKing and get a free book.
> www.parasoft.com/bulletproofapps1
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>

Re: [Dev-C++] STL Map question

[Shane B. <ast...@te...>]

Actually, since I had about 20 responses on this topic, none of which
actually got close to the effect, nevermind the cause of the problem, I will
try and explain the situation in more detail.  However, to make the records
clear, I don't expect to find an answer now.  I have looked the code over a
number of times, and had another expert which is admittedly significantly
better with C++ and STL than myself, and even he cannot seem to find any
problems which relate.  Given old working code, and my new adjusted code,
many changes were made but I cannot determine what is causing the problem.

Now, the effect of the issue, is as follows. A network of 6,000-10,000
active users at any given time is regulated by a security service.  This
service runs and connects like a user, with special priviledges.  Anytime a
user connects to the network, the services is informed, and the User is
added to a global UserList.  The network also has smaller units, known as
Channels.  Each Channel contains 3 UserList's as well.  First, depicts all
users in the Channel, the second depicts all the operators of the channel,
and the third depicts the priviledged users who are not operators.  99% of
the time, the code work fine.  Users constantly added and removed from the
list.  Periodically, what seems like an issue without a pattern, the code
will crash with a segmentation fault while trying to call
"std::map<>::find()", with a valid key.  Whether the key is in the map, is
not definate, but the key passed in valid and should not have a problem
being searched.

This said, I have narrowed the issue down to one of 2 causes. 1) Either
User's are being added to lists, and not being removed, and the UserLists
are eventually gathering enough garbage that out of memory is being
encountered. The application has a signal hook for out of memory, and it is
not being raised.  So I am leaning more towards option 2) The User class is
being deleted, without being removed from the UserList.  However, I can find
no indication of this in the code.  The code is many thousands of lines, it
is not a small project by any means.  Providing the source for the issue,
would require the entire project as the issue is not specifically a syntax
issue, but rather a situational issue.  I do believe something has
invalidated a User class, which a UserList has a pointer to, and when trying
to use it, is causing a segmentation fault.  I'm sure most of the experts
here will agree with my conclusion and realize tracing this problem is no
easy task.

I've considered some commercial products like Purify, or some other memory
tracking products, but I have no experience with any, since I've never had
an issue I couldn't resolve purely with GDB.  Since the problem traces back
most likely to an invalid pointer reference, does anyone have suggestions on
how I could possibly detect where the pointer is being deleted?  I've
considered the idea of using smart pointers to track the issue down, but
again I'm not entirely certain of how to implement some code to track where
the User is being deleted without being removed from the channels they are
in... It could also potentially be an issue with overwritting memory, but
with how often it is caused in exactly the same way, it's unlikely to be
memory overbounding.
I noticed a location where the key being used was being changed (a
nickname), and in those cases, where the old code would just rename the
nickname, I have now remove from the map and then readd to the map. When it
tries to remove from the map is when it crashes.  I can only assume that the
problem is an invalid pointer, thus the map::find function is crashing
because of invalid memory.  The key was based on a const char *, but the
other expert I consulted suggested using std::string to help track the
problem until it is found... Changing to use std::string is how I determined
that the key was still valid (because it had a copy of the nick instead of a
pointer to the nick which may be invalidated at some point), and the key was
still intact as far as I can remember, the pointer however caused GDB itself
to indicate that the program crashed again from a call by GDB, when trying
to access a member of the pointer.


Okay, hopefully these details will clarify for all the people who tried to
help... The problem itself is not something so simple as was suggested so
far.  However, Hossein did make one point that I should have realized
myself.  Not that it matters, but I should use empty() instead of size() ==
0, since it's possible empty() can execute faster than size().  But speaking
from the ANSI compliance, size() == 0 is identical to empty() == true in
result, just not exection.  That said, it will not affect the problem.

    -Shane
----- Original Message ----- 
From: "Hossein Haeri" <ult...@em...>
To: <dev...@li...>
Sent: Friday, July 11, 2003 5:19 AM
Subject: RE: [Dev-C++] STL Map question


> I'm not sure if it helps, but just try (!map<>::empty()) instead of
> (map<>::size() > 0) to see what happens!
>
> Sorry if it seems a little off-topic. But that's because I still
> couldn't realise what had caused the bug. I'm trying to check if there
> is any bug in your C++ implementation's std::map<>. Maybe,
> map<>::size() does something causing pointer invalidation!
>
> Let me know the result!
>
> Regards,
> --Hossein
> -- 
> __________________________________________________________
> Sign-up for your own FREE Personalized E-mail at Mail.com
> http://www.mail.com/?sr=signup
>
> CareerBuilder.com has over 400,000 jobs. Be smarter about your job search
> http://corp.mail.com/careers
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Parasoft
> Error proof Web apps, automate testing & more.
> Download & eval WebKing and get a free book.
> www.parasoft.com/bulletproofapps1
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>

Re: [Dev-C++] need help!

[Per W. <pw...@ia...>]

I have deleted the original question and Adam's answer, so I can't check
the full-text messages.

However, where in Adam's response did you see any "heavy" sarcasms? The
citated part does mention FindFirst/FindNext/... and the very valid remark
that FindClose() must be used.

It is a very, very common mistake to forget the FindClose(), since since
the program would leak handles and memory resources without the call -
resulting in future failures if the directory scan is performed multiple
times without restart of the application.

/Per W

On Fri, 11 Jul 2003, [ISO-8859-2] OROSZI Bal=E1zs wrote:

> Adam Malinowski wrote:
> >>I am new to C++. I like to read files name in the folder . For an examp=
le,
> >>My path is "C:\temp\data ", and in the folder there are some files that=
 i
> >>need to read only file name like file1.dat , file2.dat , file3.dat ....
> >
> > all
> >
> >>my dat file. If anyone have any advice or good idea how to write this
> >>function for me I will be very happy. Thank you very much
> >>
> >
> > Try FindFirst and FindNext or FindFirstFile and FindNextFile.
> > You can specify diiferent parameters and file extension is one of them.
> >
> > FindFirst and aFindNext belongs to VCL library.
> > FindFirstFile and FindNextFile are Win32 API functions.
> >
> > Remember to use FindClose.
>
> Don't you think this was a bit "strong" or "heavy" for sarcasm?
>
> --
> Greetings,
>    Bal=E1zs
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Parasoft
> Error proof Web apps, automate testing & more.
> Download & eval WebKing and get a free book.
> www.parasoft.com/bulletproofapps1
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>

Re: [Dev-C++] need help!

[<or...@vp...>]

Adam Malinowski wrote:
>>I am new to C++. I like to read files name in the folder . For an example,
>>My path is "C:\temp\data ", and in the folder there are some files that i
>>need to read only file name like file1.dat , file2.dat , file3.dat ....
> 
> all
> 
>>my dat file. If anyone have any advice or good idea how to write this
>>function for me I will be very happy. Thank you very much
>>
> 
> Try FindFirst and FindNext or FindFirstFile and FindNextFile.
> You can specify diiferent parameters and file extension is one of them.
> 
> FindFirst and aFindNext belongs to VCL library.
> FindFirstFile and FindNextFile are Win32 API functions.
> 
> Remember to use FindClose.

Don't you think this was a bit "strong" or "heavy" for sarcasm?

--
Greetings,
   Balázs

RE: [Dev-C++] new mail TX5Do7qV

[Smurf, P. <smu...@xs...>]

V2VsbCBseWNvcyBFdXJvcGUgaXMgb3ZlciBoZXJlOiBodHRwOi8vd3d3Lmx5Y29zLWV1cm9w
ZS5jb20vDQoNCkhvd2V2ZXIgeW91IG1heSBiZSBpbnRlcmVzdGVkIGluIHRoZSBFbmdsaXNo
IG9mZmVyaW5nIHlvdSB3aWxsIGZpbmQgaXQgaGVyZToNCmh0dHA6Ly93d3cubHljb3MuY28u
dWsvDQpUaGUgZW1haWwgb2ZmZXJpbmc6IGh0dHA6Ly9tYWlsLmx5Y29zLmNvLnVrLyAoMTVN
QiBvZiBzcGFjZSkNClRha2UgYSB0b3VyIG9mIHRoZSB3ZWJzaXRlIG9mZmVyaW5nOiBodHRw
Oi8vd3d3LnRyaXBvZC5seWNvcy5jby51ay90YWtldG91ci8NCihQSFAgKyBGcm9udFBhZ2Ug
ZXh0ZW5zaW9ucyBhbmQgYSBkYXRhYmFzZSA1MCBNQiBtYXgpDQoNCkJ1dCBpdCBjYW4gYmUg
c2xvdyBhdCBwZWFrIGhvdXJzLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv
bTogUm9kb2xmbyBPY2hvYSBbbWFpbHRvOmNvZGVyaHlicmlkdW1AeWFob28uY29tLm14XQ0K
U2VudDogZG9uZGVyZGFnIDExIGp1bGkgMjAwMiAxNToyNw0KVG86IFNtdXJmLCBQYXBhDQpT
dWJqZWN0OiBSZTogW0Rldi1DKytdIG5ldyBtYWlsIFRYNURvN3FWDQoNCg0KdGhlIGFkZHJl
cyBmcm9tIGx5Y29zIEV1cm9wZSA/Pw0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0t
DQpGcm9tOiAiU211cmYsIFBhcGEiIDxzbXVyZl93d3dAeHM0YWxsLm5sPg0KVG86IDxscmNs
YXVzZUByZWRlbGxpcHNlLm5ldD47ICJEZXYtY3BwLXVzZXJzIg0KPGRldi1jcHAtdXNlcnNA
bGlzdHMuc291cmNlZm9yZ2UubmV0Pg0KU2VudDogRnJpZGF5LCBKdWx5IDExLCAyMDAzIDc6
MzUgQU0NClN1YmplY3Q6IFJFOiBbRGV2LUMrK10gbmV3IG1haWwgVFg1RG83cVYNCg0KDQo+
IEx5Y29zIG9mZmVycyB0aGUgc2FtZS4gV2VsbCBMeWNvcyBFdXJvcGUgZG9lcyBhbmQgeW91
IGdldCBhIDUwIE1CIHdlYnNpdGUNCj4gd2l0aCBQSFA0IGFuZCBNeVNRTCBzdXBwb3J0IGFs
bCBmb3IgZnJlZS4NCj4NCj4gQlVUIFdIQVQgSSBNRUFOIElTIE5PIFNQQU0hDQo+DQo+DQo+
DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGRldi1jcHAtdXNlcnMt
YWRtaW5AbGlzdHMuc291cmNlZm9yZ2UubmV0DQo+IFttYWlsdG86ZGV2LWNwcC11c2Vycy1h
ZG1pbkBsaXN0cy5zb3VyY2Vmb3JnZS5uZXRdT24gQmVoYWxmIE9mDQo+IGxyY2xhdXNlQHJl
ZGVsbGlwc2UubmV0DQo+IFNlbnQ6IHZyaWpkYWcgMTEganVsaSAyMDAzIDE0OjE1DQo+IFRv
OiBEZXYtY3BwLXVzZXJzDQo+IFN1YmplY3Q6IFtEZXYtQysrXSBuZXcgbWFpbCBUWDVEbzdx
Vg0KPg0KPg0KPiDM+yDw4OT7IO/w5eTr7ubo8vwg4uDsIO3u4vvpIOHl8e/r4PLt++kg7+73
8u7i++kg8eXw4ujxDQo+IGh0dHA6Ly93d3cubWFpbDE1LmNvbS4gxePuIO7y6+j36PLl6/zt
++Ug7vHu4eXt7e7x8ug6DQo+IDEpIPDg5+zl8CD/+ejq4CAxNSDs4TsNCj4gMikg5+D56Pnl
7e3u8fL8IOgg7eDk5ebt7vHy/DsNCj4gMykg4u7n7O7m7e7x8vwg6PHv7uv85+7i4O3o/yDr
/uH79SDv7vfy7uL79SDv8O7j8ODs7ChQT1AsSU1BUCxTTVRQKTsNCj4gNCkg5O7x8vPvIOjn
IOv+4e7j7iDs5fHy4CDiIOv+4e7lIOLw5ez/Ow0KPiA1KSDv8O7x8u7pIOgg5O7x8vPv7fvp
IOLl4ejt8uXw9OXp8SDxIM/Oy83bzCDO0tHT0tHSwsjFzCDQxcrLwMzbOw0KPiA2KSDg7fLo
4ujw8/Ht++kg6CDg7fLo8e/g7O7i++kg6u7t8vDu6/w7DQo+IDcpIOzj7e7i5e3t4P8g7+Xw
5fH76+rgIO/u9/L7Lg0KPg0KPiDF8evoIOL7IO3lIPXu8ujy5SDv7uvz9+Dy/CDh7uvl5SDk
4O3t8/4g8ODx8fvr6vMsIO/o+Ojy5Q0KPiBtYWlsdG86dW5zdWJzY3JpYmVAbWFpbDE1LmNv
bT9zdWJqZWN0PXVuc3Vic2NyaWJlDQo+DQo+ICoqKioqKioqKioqKioNCj4NCj4gIFdlIGFy
ZSBnbGFkIHRvIGludml0ZSB5b3UgYXQgbmV3IGZyZWUgbWFpbCBzZXJ2aWNlIGh0dHA6Ly93
d3cubWFpbDE1LmNvbS4NCj4gVGhlIGFkdmFudGFnZXMgb2YgdGhpcyBzZXJ2aWNlIGFyZToN
Cj4gIDEpIG1haWxib3gsIHVwIHRvIDE1IE1iOw0KPiAgMikgYWJzb2x1dGUgcHJpdmFjeSBh
bmQgaGlnaCByZWxpYWJpbGl0eTsNCj4gIDMpIGFiaWxpdHkgdG8gdXNlIG1haWwgY2xpZW50
cyAoUE9QMywgSU1BUDQsIFNNVFApOw0KPiAgNCkgYWNjZXNzIGZyb20gYW55d2hlcmUsIGFu
eXRpbWU7DQo+ICA1KSBmbGV4aWJsZSBsaWdodC13ZWlnaHQgd2ViIGludGVyZmFjZSB3aXRo
b3V0IGFkdmVydGlzaW5nIGJhbm5lcnM7DQo+ICA2KSBhbnRpdmlydXMgYW5kIGFudGlzcGFt
IGNvbnRyb2w7DQo+ICA3KSBmYXN0IG1haWwgdHJhbnNmZXI7DQo+ICA4KSBoaWdoIHNwZWVk
IG5ldHdvcmsgY2hhbm5lbDsNCj4gIDkpIGZsZXhpYmxlIGxpZ2h0LXdlaWdodCB3ZWIgaW50
ZXJmYWNlOw0KPiAgMTApIHdpZGUgc3ByZWFkIGFiaWxpdHkgb2YgbWFpbCBmaWx0ZXJpbmcg
YW5kIGZvcndhcmRpbmcgbWFpbDsNCj4gIDExKSBjbG9jayBhcm91bmQgc3VwcG9ydDsNCj4N
Cj4gIElmIHlvdSB3aXNoIHRvIGJlIHJlbW92ZWQ6DQo+IG1haWx0bzp1bnN1YnNjcmliZUBt
YWlsMTUuY29tP3N1YmplY3Q9dW5zdWJzY3JpYg0KPg0KPiBrb0pLdGV0UG12DQo+DQo+DQo+
DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0NCj4gVGhpcyBTRi5OZXQgZW1haWwgc3BvbnNvcmVkIGJ5OiBQYXJhc29mdA0KPiBF
cnJvciBwcm9vZiBXZWIgYXBwcywgYXV0b21hdGUgdGVzdGluZyAmIG1vcmUuDQo+IERvd25s
b2FkICYgZXZhbCBXZWJLaW5nIGFuZCBnZXQgYSBmcmVlIGJvb2suDQo+IHd3dy5wYXJhc29m
dC5jb20vYnVsbGV0cHJvb2ZhcHBzMQ0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KPiBEZXYtY3BwLXVzZXJzIG1haWxpbmcgbGlzdA0KPiBE
ZXYtY3BwLXVzZXJzQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KPiBUTyBVTlNVQlNDUklCRTog
aHR0cDovL3d3dzIzLmJyaW5rc3Rlci5jb20vbm9pY3lzL2RldmNwcC91Yi5odG0NCj4gaHR0
cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vZGV2LWNwcC11c2Vy
cw0KPg0KPiBOSLWKoq3IarSionmmtrWygniedZUqanqtosOtfpuWpn2zvbqylpameoqyca56
UAUNCrb/24q1oqKzvf62aG22mz/+WKy2yyi6tx5+iuB6d63+WKy2z+WKy2Kd+j9169ymm6wN
Cg0KDQo=

RE: [Dev-C++] Constructor and Destructor

[Ioannis V. <iv...@em...>]

> -----Original Message-----
> From: Hossein Haeri [mailto:ult...@em...] 
> Sent: Friday, July 11, 2003 1:51 PM
> To: Ioannis Vranos
> Cc: dev...@li...
> Subject: RE: [Dev-C++] Constructor and Destructor
> 
> 
> Provided that lifetime of the pointing object is ended. Consider the
> following line of citation I had made from the Standard:
> 
> > >   pb->f(); //undefined behavior, lifetime of *pb has ended
> 
> Let me know if I haven't still got the point you had meant.


Yes, in our case there has never been an object.






Ioannis Vranos
 
* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

[Dev-C++] (no subject)

[<dei...@ya...>]

 Hi.
 
 I would like to know how can I can detect that a new
IE window is being opened and if I would be able to
stop it or log events of that window.

 Thanks in advance, 

 InacioW-


__________________________________________________________________

Gesendet von Yahoo! Mail - http://mail.yahoo.de
Logos und Klingeltöne fürs Handy bei http://sms.yahoo.de

RE: [Dev-C++] new mail TX5Do7qV

[Smurf, P. <smu...@xs...>]

THljb3Mgb2ZmZXJzIHRoZSBzYW1lLiBXZWxsIEx5Y29zIEV1cm9wZSBkb2VzIGFuZCB5b3Ug
Z2V0IGEgNTAgTUIgd2Vic2l0ZQ0Kd2l0aCBQSFA0IGFuZCBNeVNRTCBzdXBwb3J0IGFsbCBm
b3IgZnJlZS4NCg0KQlVUIFdIQVQgSSBNRUFOIElTIE5PIFNQQU0hDQoNCg0KDQotLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogZGV2LWNwcC11c2Vycy1hZG1pbkBsaXN0cy5z
b3VyY2Vmb3JnZS5uZXQNClttYWlsdG86ZGV2LWNwcC11c2Vycy1hZG1pbkBsaXN0cy5zb3Vy
Y2Vmb3JnZS5uZXRdT24gQmVoYWxmIE9mDQpscmNsYXVzZUByZWRlbGxpcHNlLm5ldA0KU2Vu
dDogdnJpamRhZyAxMSBqdWxpIDIwMDMgMTQ6MTUNClRvOiBEZXYtY3BwLXVzZXJzDQpTdWJq
ZWN0OiBbRGV2LUMrK10gbmV3IG1haWwgVFg1RG83cVYNCg0KDQrM+yDw4OT7IO/w5eTr7ubo
8vwg4uDsIO3u4vvpIOHl8e/r4PLt++kg7+738u7i++kg8eXw4ujxDQpodHRwOi8vd3d3Lm1h
aWwxNS5jb20uIMXj7iDu8uvo9+jy5ev87fvlIO7x7uHl7e3u8fLoOg0KMSkg8ODn7OXwIP/5
6OrgIDE1IOzhOw0KMikg5+D56Pnl7e3u8fL8IOgg7eDk5ebt7vHy/DsNCjMpIOLu5+zu5u3u
8fL8IOjx7+7r/Ofu4uDt6P8g6/7h+/Ug7+738u7i+/Ug7/Du4/Dg7OwoUE9QLElNQVAsU01U
UCk7DQo0KSDk7vHy8+8g6Ocg6/7h7uPuIOzl8fLgIOIg6/7h7uUg4vDl7P87DQo1KSDv8O7x
8u7pIOgg5O7x8vPv7fvpIOLl4ejt8uXw9OXp8SDxIM/Oy83bzCDO0tHT0tHSwsjFzCDQxcrL
wMzbOw0KNikg4O3y6OLo8PPx7fvpIOgg4O3y6PHv4Ozu4vvpIOru7fLw7uv8Ow0KNykg7OPt
7uLl7e3g/yDv5fDl8fvr6uAg7+738vsuDQoNCsXx6+gg4vsg7eUg9e7y6PLlIO/u6/P34PL8
IOHu6+XlIOTg7e3z/iDw4PHx++vq8ywg7+j46PLlDQptYWlsdG86dW5zdWJzY3JpYmVAbWFp
bDE1LmNvbT9zdWJqZWN0PXVuc3Vic2NyaWJlDQoNCioqKioqKioqKioqKioNCg0KIFdlIGFy
ZSBnbGFkIHRvIGludml0ZSB5b3UgYXQgbmV3IGZyZWUgbWFpbCBzZXJ2aWNlIGh0dHA6Ly93
d3cubWFpbDE1LmNvbS4NClRoZSBhZHZhbnRhZ2VzIG9mIHRoaXMgc2VydmljZSBhcmU6DQog
MSkgbWFpbGJveCwgdXAgdG8gMTUgTWI7DQogMikgYWJzb2x1dGUgcHJpdmFjeSBhbmQgaGln
aCByZWxpYWJpbGl0eTsNCiAzKSBhYmlsaXR5IHRvIHVzZSBtYWlsIGNsaWVudHMgKFBPUDMs
IElNQVA0LCBTTVRQKTsNCiA0KSBhY2Nlc3MgZnJvbSBhbnl3aGVyZSwgYW55dGltZTsNCiA1
KSBmbGV4aWJsZSBsaWdodC13ZWlnaHQgd2ViIGludGVyZmFjZSB3aXRob3V0IGFkdmVydGlz
aW5nIGJhbm5lcnM7DQogNikgYW50aXZpcnVzIGFuZCBhbnRpc3BhbSBjb250cm9sOw0KIDcp
IGZhc3QgbWFpbCB0cmFuc2ZlcjsNCiA4KSBoaWdoIHNwZWVkIG5ldHdvcmsgY2hhbm5lbDsN
CiA5KSBmbGV4aWJsZSBsaWdodC13ZWlnaHQgd2ViIGludGVyZmFjZTsNCiAxMCkgd2lkZSBz
cHJlYWQgYWJpbGl0eSBvZiBtYWlsIGZpbHRlcmluZyBhbmQgZm9yd2FyZGluZyBtYWlsOw0K
IDExKSBjbG9jayBhcm91bmQgc3VwcG9ydDsNCg0KIElmIHlvdSB3aXNoIHRvIGJlIHJlbW92
ZWQ6DQptYWlsdG86dW5zdWJzY3JpYmVAbWFpbDE1LmNvbT9zdWJqZWN0PXVuc3Vic2NyaWIN
Cg0Ka29KS3RldFBtdg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyBTRi5OZXQgZW1haWwgc3BvbnNvcmVkIGJ5
OiBQYXJhc29mdA0KRXJyb3IgcHJvb2YgV2ViIGFwcHMsIGF1dG9tYXRlIHRlc3RpbmcgJiBt
b3JlLg0KRG93bmxvYWQgJiBldmFsIFdlYktpbmcgYW5kIGdldCBhIGZyZWUgYm9vay4NCnd3
dy5wYXJhc29mdC5jb20vYnVsbGV0cHJvb2ZhcHBzMQ0KX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCkRldi1jcHAtdXNlcnMgbWFpbGluZyBsaXN0
DQpEZXYtY3BwLXVzZXJzQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KVE8gVU5TVUJTQ1JJQkU6
IGh0dHA6Ly93d3cyMy5icmlua3N0ZXIuY29tL25vaWN5cy9kZXZjcHAvdWIuaHRtDQpodHRw
czovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9kZXYtY3BwLXVzZXJz
DQoNCg==

[Dev-C++] new mail TX5Do7qV

[<lrc...@re...>]

Мы рады предложить вам новый бесплатный почтовый сервис http://www.mail15.com. Его отличительные особенности:
1) размер ящика 15 мб;
2) защищенность и надежность;
3) возможность использования любых почтовых программ(POP,IMAP,SMTP);
4) доступ из любого места в любое время;
5) простой и доступный вебинтерфейс с ПОЛНЫМ ОТСУТСТВИЕМ РЕКЛАМЫ;
6) антивирусный и антиспамовый контроль;
7) мгновенная пересылка почты.

Если вы не хотите получать более данную рассылку, пишите mailto:uns...@ma...?subject=unsubscribe

*************

 We are glad to invite you at new free mail service http://www.mail15.com. The advantages of this service are:
 1) mailbox, up to 15 Mb;
 2) absolute privacy and high reliability;
 3) ability to use mail clients (POP3, IMAP4, SMTP);
 4) access from anywhere, anytime;
 5) flexible light-weight web interface without advertising banners;
 6) antivirus and antispam control;
 7) fast mail transfer;
 8) high speed network channel;
 9) flexible light-weight web interface;
 10) wide spread ability of mail filtering and forwarding mail;
 11) clock around support;

 If you wish to be removed:
mailto:uns...@ma...?subject=unsubscrib

koJKtetPmv

RE: [Dev-C++] STL Map question

[Hossein H. <ult...@em...>]

I'm not sure if it helps, but just try (!map<>::empty()) instead of
(map<>::size() > 0) to see what happens! 

Sorry if it seems a little off-topic. But that's because I still
couldn't realise what had caused the bug. I'm trying to check if there
is any bug in your C++ implementation's std::map<>. Maybe,
map<>::size() does something causing pointer invalidation!

Let me know the result!

Regards,
--Hossein
-- 
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

CareerBuilder.com has over 400,000 jobs. Be smarter about your job search
http://corp.mail.com/careers

[Dev-C++] The STL book is...

[Daniel G. <sp...@ho...>]

Generic Programming and the STL
Using and extending the C++ Standard Template Library

Amazon reviewers (uk site) gave it between 4 and 5 stars, they do keep 
saying that the book expects you to know a bit about the STL from the start 
though.

There must be better books around.

_________________________________________________________________
Hotmail messages direct to your mobile phone http://www.msn.co.uk/msnmobile