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

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

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

Q2FuIHNvbWVvbmUgcGxlYXNlIGJsb2NrIHRoaXMgc3BhbW1lcj8NCg0KLS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS0NCkZyb206IGRldi1jcHAtdXNlcnMtYWRtaW5AbGlzdHMuc291cmNl
Zm9yZ2UubmV0DQpbbWFpbHRvOmRldi1jcHAtdXNlcnMtYWRtaW5AbGlzdHMuc291cmNlZm9y
Z2UubmV0XU9uIEJlaGFsZiBPZg0KZ2VyZ0B1bmlzb2x2ZS5jb20uYXUNClNlbnQ6IG1hYW5k
YWcgMTQganVsaSAyMDAzIDE0OjE2DQpUbzogRGV2LWNwcC11c2Vycw0KU3ViamVjdDogW0Rl
di1DKytdIG5ldyBtYWlsIHRWeW1NVmlCDQoNCg0KRW5nbGlzaCB2ZXJzaW9uICB8ICDQ8/Hx
6ujpIOLg8Ojg7fINCg0KzPsg8ODk+yDv8OXk6+7m6PL8IOLg7CDt7uL76SDh5fHv6+Dy7fvp
IO/u9/Lu4vvpIPHl8OLo8Q0KaHR0cDovL3d3dy5tYWlsMTUuY29tLiDF4+4g7vLr6Pfo8uXr
/O375SDu8e7h5e3t7vHy6DoNCjEpIPDg5+zl8CD/+ejq4CAxNSDs4TsNCjIpIOfg+ej55e3t
7vHy/CDoIO3g5OXm7e7x8vw7DQozKSDi7ufs7ubt7vHy/CDo8e/u6/zn7uLg7ej/IOv+4fv1
IO/u9/Lu4vv1IO/w7uPw4OzsKFBPUCxJTUFQLFNNVFApOw0KNCkg5O7x8vPvIOjnIOv+4e7j
7iDs5fHy4CDiIOv+4e7lIOLw5ez/Ow0KNSkg7/Du8fLu6SDoIOTu8fLz7+376SDi5eHo7fLl
8PTl6fEg8SDPzsvN28wgztLR09LR0sLIxcwg0MXKy8DM2zsNCjYpIODt8uji6PDz8e376SDo
IODt8ujx7+Ds7uL76SDq7u3y8O7r/DsNCjcpIOzj7e7i5e3t4P8g7+Xw5fH76+rgIO/u9/L7
Lg0KDQrF8evoIOL7IO3lIPXu8ujy5SDv7uvz9+Dy/CDh7uvl5SDk4O3t8/4g8ODx8fvr6vMs
IO/o+Ojy5Q0KbWFpbHRvOnVuc3Vic2NyaWJlQG1haWwxNS5jb20/c3ViamVjdD11bnN1YnNj
cmliZQ0KDQoqKioqKioqKioqKioqDQoNCiBXZSBhcmUgZ2xhZCB0byBpbnZpdGUgeW91IGF0
IG5ldyBmcmVlIG1haWwgc2VydmljZSBodHRwOi8vd3d3Lm1haWwxNS5jb20uDQpUaGUgYWR2
YW50YWdlcyBvZiB0aGlzIHNlcnZpY2UgYXJlOg0KIDEpIG1haWxib3gsIHVwIHRvIDE1IE1i
Ow0KIDIpIGFic29sdXRlIHByaXZhY3kgYW5kIGhpZ2ggcmVsaWFiaWxpdHk7DQogMykgYWJp
bGl0eSB0byB1c2UgbWFpbCBjbGllbnRzIChQT1AzLCBJTUFQNCwgU01UUCk7DQogNCkgYWNj
ZXNzIGZyb20gYW55d2hlcmUsIGFueXRpbWU7DQogNSkgZmxleGlibGUgbGlnaHQtd2VpZ2h0
IHdlYiBpbnRlcmZhY2Ugd2l0aG91dCBhZHZlcnRpc2luZyBiYW5uZXJzOw0KIDYpIGFudGl2
aXJ1cyBhbmQgYW50aXNwYW0gY29udHJvbDsNCiA3KSBmYXN0IG1haWwgdHJhbnNmZXI7DQog
OCkgaGlnaCBzcGVlZCBuZXR3b3JrIGNoYW5uZWw7DQogOSkgZmxleGlibGUgbGlnaHQtd2Vp
Z2h0IHdlYiBpbnRlcmZhY2U7DQogMTApIHdpZGUgc3ByZWFkIGFiaWxpdHkgb2YgbWFpbCBm
aWx0ZXJpbmcgYW5kIGZvcndhcmRpbmcgbWFpbDsNCiAxMSkgY2xvY2sgYXJvdW5kIHN1cHBv
cnQ7DQoNCiBJZiB5b3Ugd2lzaCB0byBiZSByZW1vdmVkOg0KbWFpbHRvOnVuc3Vic2NyaWJl
QG1haWwxNS5jb20/c3ViamVjdD11bnN1YnNjcmliDQoNCnRVcWU1QnluZFQNCg0KDQoNCi0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N
ClRoaXMgU0YuTmV0IGVtYWlsIHNwb25zb3JlZCBieTogUGFyYXNvZnQNCkVycm9yIHByb29m
IFdlYiBhcHBzLCBhdXRvbWF0ZSB0ZXN0aW5nICYgbW9yZS4NCkRvd25sb2FkICYgZXZhbCBX
ZWJLaW5nIGFuZCBnZXQgYSBmcmVlIGJvb2suDQp3d3cucGFyYXNvZnQuY29tL2J1bGxldHBy
b29mYXBwczENCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fDQpEZXYtY3BwLXVzZXJzIG1haWxpbmcgbGlzdA0KRGV2LWNwcC11c2Vyc0BsaXN0cy5z
b3VyY2Vmb3JnZS5uZXQNClRPIFVOU1VCU0NSSUJFOiBodHRwOi8vd3d3MjMuYnJpbmtzdGVy
LmNvbS9ub2ljeXMvZGV2Y3BwL3ViLmh0bQ0KaHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5u
ZXQvbGlzdHMvbGlzdGluZm8vZGV2LWNwcC11c2Vycw0KDQo=

RE: [Dev-C++] String << operator overloaded (using template)

[Jaap de W. <wo...@ne...>]

At my place it works.
I made a class myclass to test, see below.


-----Original Message-----
>From: David McKen [mailto:ci...@ya...]
>Sent: Sunday, July 13, 2003 8:02 PM
>To: Dev-Cpp Mailing List
>Subject: [Dev-C++] String << operator overloaded (using template)
>
...

#include <string>
#include <sstream>
#include <iostream>


class myclass {
public:
	myclass (int n) { member = n; }
private:
	int member;
	friend std::iostream& operator<< (std::iostream& str, class myclass
&val);
};

std::iostream& operator<< (std::iostream& str, class myclass &val){str <<
val.member;return str;}


template <class in_type>
std::string& operator<< (std::string& output, in_type& data)
{
  std::stringstream ss;
  ss << data;
  ss >> output;
  return output;
}


void main()
{
	std::stringstream ss;
	std::string sout;
	myclass hulp (15);
	sout << hulp;
	std::cout << sout;
}

[Dev-C++] new mail tVymMViB

[<ge...@un...>]

English version  |  Русский вариант

Мы рады предложить вам новый бесплатный почтовый сервис 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

tUqe5ByndT

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

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

Dear Ioannis,

> > > Eh? Why? Both have the same speed, actually empty is usually 
> > > 
> > > // inside the class definition
> > > bool empty() const {  return size()==0; }
> > 
> > This can be the case, but that isn't always true.
> > 
> > I know that holds for many of STL platforms, but they do not have to
> > follow that way.
> 
> 
> Yes. Any implementor can follow his way, the standard defines only the
> template interface but the above is a reasonable implementation. And I got
> it straight  from TC++PL 3. :-)

But that even doesn't mean that there aren't any other reasonable
implementations.

> It is not required by the standard but it would be prudent to not calculate
> size() every time it is called. Also if I would have a choice between
> storing information on whether it is empty or the size I would have chosen
> the size since the empty can be estimated by the size and would require less
> checks in the instance of the code where I would have placed a lot of checks
> if the empty value is true or false and change it.

Had you read "Effective STL," this has't been your answer. Sometimes,
there are policies such as willing to have a constant-time operation
on the map that have higher proiority for the implementer (for any
reason they know). And achieving that runtime needs you to cut down
the use of size update after any operation of the map.

I think the existance of nasty C++ implementations such as VC++6,
reveals that this is not just a fiction, and there even are wellknown
implementations who may have chosen that way.

> Anyway as I said only the interface is required by the standard but in C++
> world all strive for maximum performance.

You'r right. But max-performance of what? I mean, if there is an
operation, say O, that has higher priority from your point of view (as
the implementer, or disigner, etc.), and you want O to be done in a
constant time, and that forces you to forget updating size after O,
will you still think that max-performance obliges you to have size as
an internal member? Haven't you ever encountered nasty
implementations such as VC++6 that often have such higher priority
operations that don't seem to be reasonable at all? I have just
realised that the compiler we were talking about was GCC, and I 
hartapologise for the suspection I have had to his majesty. But
remember that I didn't know that's GCC. Knowing that, don't you still
preserve me the right of suspecting the implementation?

> > (If you want me to address the citation precisely, it is in Section
> > 9.1.1, i.e., Container. And the complete bibliography is:
> > 
> > Matthew H. Austern, Generic Programming and the STL: Using and
> > Extending the C++ Standard Template Library, Addisson Wesley, 1999,
> > ISBN: 0-201-30956-4.)
> > 
> > These lines make me to become more sure that there isn't any guarantee
> > in the Standard for size() and empty() to be equal in the sense of
> > runtime.
> 
> 
> 
> Of course there is not. Nor there is any guarantee on which is faster nor
> whether it takes milliseconds, seconds and weeks. However as I said what I
> provided is a reasonable implementation.

But, I want to mention one time more that, that doesn't mean the
shortage of any other reasonable one.

> Yes. It may also calculate the 1000 first digits of pi (3.14..) in the
> meantime, but we are discussing reasonable implementations and having to
> calculate the size() of every container that provides size() each time it is
> called (and it may have millions) doesn't sound too reaaonable to me.

Come on! I'm not joking! Even if that's not reasonable at all,
remember that there are largely-used implementations such as VC++6
that often make those mistakes.

> Yes, it may has decided manyy things. However we mau assume that all member
> functions are maximally efficient, else throw the platform away!

I agree with you in the sense of efficiency, but remember the problem
with (sometimes unwanted) priorities.

Furthermore, sometimes, the dicision of throwing a platform away is
not whithin our duty. Nor can we complain on it. E.g., the project may
be in a platform that is used for years and years, and changing it
imposes more cost to the wendors. As an other example, you may be one
of the ordinary programmers in more than 1000, in a software-house
that wants its products to have good GUIs, and so have chosen VC++6 as
they don't want to waste time for reinvnting the wheel! They may well
know about the vast erea of VC++6's bugs, but they have to tollerate
against it. So they are not going to change the platform. What would
you do then?

> > You may still think that there empty() and size() have the same
> > runtime. But that doesn't mean there are equal in any case. If you
> > have any doubt on this issue, consider Item 4 of Effective STL.
> 
> 
> Read TC++PL 3. Straight from the creator of C++.

Oh! That's a great book. The best "General Purpose" book in C++. I
read TC++PL:Spec, couple of years ago. (I myself, was teaching C++ in
university at those days, but unfortunately, I hadn't the opportunity
of reading that great book before. It was great and I found tones of
new fine points in it.) From that time, it's the first reference of
my C++ courses in university, and I'm very proud of it.

But that doesn't mean that the other books do not have any stuff to
mention. "Effective STL," for example, is one of the best books in the
history of C++, and is the most expert book in STL, indeed.

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

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

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

Dear Shane,
> *boggle* You haven't heard of G++? GCC? These are the primary GNU based
> compiler collection, used on 99% of unix systems I know of.  

I have, I am familiar with both, and I'm using them under the hood of
Dev-C++. But I'm in doubt if you have mentioned the same name in your
first email. Please excuse me if it is my fault (as I'm a careless
man), but as I remember, the name of the implementation you had
mentioned contained a 'D' letter, didn't it? (I have deleted that
message so I can't check it anymore.)

Anyway, thank you because of the links! It is obvious that you have
made a big search and seemingly in a very angree state. It seems
either I have misread your starting email, or your have miswritten it.
I do appolgise if  the first is the case!

> ... I would dare say GCC is
> likely used on a wider scale than Visual C++, or any other C/C++ compiler
> I'm aware of.

That's absolutely right! Definitely!

> ... My next step, is to look into some tools for debugging memory problems. I'm
> sure the program has hoards of them, but it would be nice as I said, if I
> could trace back the usage of a memory address somehow.

IIRC, STLPort has a good tool for your purpose.

> ... Anyways, thanks for your interest, it's at least keeping my brain thinking
> about the problem. I've been avoiding it for a while... 

Your welcome! I'm sure you would do the same if the problem was mine.

> ... But I will
> let you know if I figure out the problem.

Hoping it to be solved ASAP, and looking for the solution.

Wishes,
--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

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

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

Tod...@De... wrote:
> Anyway, I am still looking for those function but still can not find it.. I
> will looking for a book for these. thanks you all your help. :-)

No need to take a book. Download the Windows API. I think it has a 
DevPak too. Check vUpdate. Then look in the index for FindFirstFile, and 
all other stuff in the Windows API.


About this sarcasm thing. Khm... Well. Sometimes my brain decides to 
stop working, but my fingers just hit the keyboard. I only noticed the 
word "Find" in Adam Malinowski's mail, and immediately I connected it 
with the "Find" option in the Dev-C++ IDE. So I thought, he suggested 
you to find what you are looking for from the IDE. Like as you were a 
total, absolute newbie to even finding stuff on your PC. My brain was 
just out for that moment, and shortly after I pressed the "Send" button, 
I realized my foolishness.

Next time, I'll wait 5 minutes before I reply to anything, and I will 
read the mail at least 5 times.

Sorry for the trouble. I meant no offense. I am just stupid.

Again, this whole thing was all my fault, but luckyly it seems it also 
brought up the fact, that FindClose must also be used :)
So it was useful... in a way.

--
Greetings,
   Balázs

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

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

Dear Eddie,

> The best book, by far, on the C++ STL is "Generic Programming and the STL"
> by Matthew H. Austern. Josuttis is a good book on the C++ Standard library
> as a whole but the Austern book, which focuses strictly on the STL, is
> superb in every respect and brilliantly organized.

Yeeeeeeeeep! Thumbs Up! One of the best books I hav ever read!
Fantastic from several points of view, without any major flaw!

Wishes,
--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

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

[<Tod...@De...>]

No.. you are fine. Those words are not sarcasm for me...I am thinking =
only
computer language term only.=20
Anyway, I am still looking for those function but still can not find =
it.. I
will looking for a book for these. thanks you all your help. :-)

Todd c.

-----Original Message-----
From: Adam Malinowski [mailto:up...@in...]
Sent: Sunday, July 13, 2003 2:07 PM
To: dev...@li...; OROSZI Bal=E1zs
Subject: Re: [Dev-C++] need help!


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

--
Greetings,
   Bal=E1zs

Hi.
I went for a weekend to place which is far from civilisation so that's =
why
my answer is so late.

I had no intetion to use any sarcasm. FindClose is very important =
element
in searching files using FindFirstFile and FindNextFile. Note tha Todd
didn't
know how to solve his problem so probably he didn't know those =
functions.
That's why i mentioned FindClose.
If Todd feels touched then i'm very sorry but it wasn't my intetion.
Thanks to other people for explanation.

Adam.




-------------------------------------------------------
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++] The STL book is...

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

> -----Original Message-----
> From: dev...@li...=20
> [mailto:dev...@li...] On Behalf=20
> Of Eddie Diener
> Sent: Monday, July 14, 2003 7:11 AM
> To: dev...@li...
> Subject: Re: [Dev-C++] The STL book is...
>=20
>=20
> The best book, by far, on the C++ STL is "Generic Programming=20
> and the STL"
> by Matthew H. Austern. Josuttis is a good book on the C++=20
> Standard library
> as a whole but the Austern book, which focuses strictly on the STL, is
> superb in every respect and brilliantly organized.



The best book is TC++PL. Of course there are many other good books and =
since
the standard is relatively new we are going to see more.


Now silence or I shall turn you to frogs! :-)






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++] The STL book is...

[Eddie D. <edd...@tr...>]

> From: "Hossein Haeri" <ult...@em...>
> To: dev...@li...
> Date: Sun, 13 Jul 2003 07:35:53 -0500
> Subject: Re: [Dev-C++] The STL book is...
>
>> 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.
>
> Do you really think that the reviews given by Amazon are enough? Take
> a look to the ACCU reviews.
> http://www.accu.org
>
>> There must be better books around.

The best book, by far, on the C++ STL is "Generic Programming and the STL"
by Matthew H. Austern. Josuttis is a good book on the C++ Standard library
as a whole but the Austern book, which focuses strictly on the STL, is
superb in every respect and brilliantly organized.

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

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

> I find that amazon reviews are normally a bit too favourable in most cases - 
> yes I'm talknig about ones by customers.
> 
> Thanks for the links.

Oops! One of the best books in STL that I had forgotten to mention is
Effective STL. I'm not sure if it is suitable in your level, but if you
have enough experience with STL not to be said beginner, then you might
have the ability of using it. The address is:

http://www.awprofessional.com/catalog/product.asp?product_id={AA4735AF-4407-4011-B7D3-0C924DFA675D}&session_id={D1375600-F675-4736-A280-9264DC16300D}

Please don't say that this book doesn't have enough stars in Amazon's
reviews, as this is the highest-level book in STL.

Another point about the following sentence in my prevoius email:

> >No there isn't. Unfortunately, there is no any better book for Generic
> >Programming. 

by "unfortunately" I didn't mean that the book is not a good one. 
Extremely opposite, it is the best in Generic Programming, and it is
really fabulous. One of the best books I have ever read. It convinces
me so much. It is great in the sense of theory, but it is as useful and
practical as the power it has in theory.

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

Re: [Dev-C++] doubts about LIBS

[staale <st...@le...>]

I do by the different compiler stuff. But the fact is that Dev-C or gcc=20
assumes a statsic (?) library to be named lib<name>.a
hmm, that was my conclusion last time I struggled with this. All I had to=20
do was to rename the library, even if it was included in the project by=20
path and name..:o)

Best Regards
Staale

At 09:23 13.07.2003 +0200, Dark Kernel \(InacioW-\) wrote:
>  Hi.
>  I tried to use ddraw.lib from M$-dxtoolkit for C++,
>and I got a missing pointer for the DLL, but when I
>linked whith libddraw.a instead of the ddraw.lib,
>everything went perfect and work as perfect as it
>would be.
>  Would someone mind about explain to me what happened?
>
>  thanks in advance,
>  InacioW-
>
>__________________________________________________________________
>
>Gesendet von Yahoo! Mail - http://mail.yahoo.de
>Logos und Klingelt=F6ne f=FCrs Handy bei http://sms.yahoo.de
>
>
>-------------------------------------------------------
>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!

[Adam M. <up...@in...>]

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

--
Greetings,
   Bal=E1zs

Hi.
I went for a weekend to place which is far from civilisation so that's wh=
y
my answer is so late.

I had no intetion to use any sarcasm. FindClose is very important element
in searching files using FindFirstFile and FindNextFile. Note tha Todd
didn't
know how to solve his problem so probably he didn't know those functions.
That's why i mentioned FindClose.
If Todd feels touched then i'm very sorry but it wasn't my intetion.
Thanks to other people for explanation.

Adam.

[Dev-C++] String << operator overloaded (using template)

[David M. <ci...@ya...>]

Could someone tell me why the following code does not work?
 
//Allows the use of << on any data type that has it defined
//into  a string.
template <class in_type>
std::string& operator<< (std::string& output, in_type& data)
{
  std::stringstream ss;
  ss << data;
  ss >> output;
  return output;
}


---------------------------------
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.

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

[<sol...@ya...>]

-O2 builds smaller executables than -O3 and -O4.
N.B. - If you want to debug, then you have to remove -s option, since -s 
means strip symbols, which are needed there for debuging. Yeah, you know 
that, I simply warn here..

OROSZI Balázs wrote:

> 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
>
>
>
>
> -------------------------------------------------------
> 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++] The STL book is...

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

I find that amazon reviews are normally a bit too favourable in most cases - 
yes I'm talknig about ones by customers.

Thanks for the links.


>From: "Hossein Haeri" <ult...@em...>
>To: dev...@li...
>Subject: Re: [Dev-C++] The STL book is...
>Date: Sun, 13 Jul 2003 07:35:53 -0500
>
> > 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.
>
>Do you really think that the reviews given by Amazon are enough? Take
>a look to the ACCU reviews.
>http://www.accu.org
>
> > There must be better books around.
>
>No there isn't. Unfortunately, there is no any better book for Generic
>Programming. There are some books who describe STL. Amongst them, one
>of the best are:
>
>http://www.josuttis.com/libbook/index.html
>
>The rest do not have much stuff to mention.
>
>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

_________________________________________________________________
It's fast, it's easy and it's free. Get MSN Messenger today! 
http://www.msn.co.uk/messenger

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

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

> 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.

Do you really think that the reviews given by Amazon are enough? Take
a look to the ACCU reviews.
http://www.accu.org

> There must be better books around.

No there isn't. Unfortunately, there is no any better book for Generic
Programming. There are some books who describe STL. Amongst them, one
of the best are:

http://www.josuttis.com/libbook/index.html

The rest do not have much stuff to mention.

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

Re: [Dev-C++] doubts about LIBS

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

Dark Kernel (InacioW-) wrote:
>  Hi.
>  I tried to use ddraw.lib from M$-dxtoolkit for C++,
> and I got a missing pointer for the DLL, but when I
> linked whith libddraw.a instead of the ddraw.lib,
> everything went perfect and work as perfect as it
> would be.
>  Would someone mind about explain to me what happened?

It is due to different compilers. I don't know DirectX, but if it is 
C++, then it is related to name mangling. MSVC and GCC mangle names 
differently, that is mainly why C++ DLLs created by MSVC cannot be used 
by programs created by GCC, and vice versa. Remember the extern "C" ... 
stuff? It is needed to disable name mangling. Simple C DLLs and 
libraries can be used by both GCC and MSVC.

Your problem lies in different compilers, that's all.

The REAL trouble comes, when the import library is inconsistent with 
it's DLL. GCC tends to do this fairly often, and it has serious trouble 
exporting C++ classes. Linking to the import library for me doesn't 
always work, but when I link to the DLL directly (which luckily, GCC can 
do), everything is fine. This is odd, but again, this is what we have to 
live with.

--
Greetings,
   Balázs

Re: [Dev-C++] doubts about LIBS

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

I had the same problem, it seems the ddraw lib is tailored for VC++ but 
because the compiler used by Dev is gcc-summatorother it doesn't have VC++#s 
faults and thus doesn't need the workarounds put into ddraw.lib

Probably rubbish what I just said, but it's a thuoght.


>From: "Dark Kernel \(InacioW-\)" <dei...@ya...>
>To: Dev...@li...
>Subject: [Dev-C++] doubts about LIBS
>Date: Sun, 13 Jul 2003 09:23:29 +0200 (CEST)
>
>  Hi.
>  I tried to use ddraw.lib from M$-dxtoolkit for C++,
>and I got a missing pointer for the DLL, but when I
>linked whith libddraw.a instead of the ddraw.lib,
>everything went perfect and work as perfect as it
>would be.
>  Would someone mind about explain to me what happened?
>
>  thanks in advance,
>  InacioW-
>
>__________________________________________________________________
>
>Gesendet von Yahoo! Mail - http://mail.yahoo.de
>Logos und Klingeltöne fürs Handy bei http://sms.yahoo.de
>
>
>-------------------------------------------------------
>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

_________________________________________________________________
On the move? Get Hotmail on your mobile phone http://www.msn.co.uk/msnmobile

[Dev-C++] doubts about LIBS

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

 Hi.
 I tried to use ddraw.lib from M$-dxtoolkit for C++,
and I got a missing pointer for the DLL, but when I
linked whith libddraw.a instead of the ddraw.lib,
everything went perfect and work as perfect as it
would be.
 Would someone mind about explain to me what happened?

 thanks in advance, 
 InacioW-

__________________________________________________________________

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

[Dev-C++] Some interesting news II

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

And this:


Next-Generation Pentium 4 to Start at 3.4GHz, Ship in October

   In second half 2003, Intel will ship its next-generation processor,
possibly to be named Pentium 5. Whatever it's called, the Pentium 4
successor will start at clock speeds of 3.4GHz and will include new
on-chip multimedia-processing instructions and a 1MB L2 cache
(compared with 512KB on the Pentium 4). A 3.6GHz version is due by
early 2004, the company says. In addition, Intel is prepping a 2.7GHz
Celeron chip for low-end PCs and is supporting chipsets for its
Pentium 5, Pentium 4, and Celeron systems that sport PCI Express I/O
and Double Data Rate 2 (DDR2) memory. On the portable end, this fall
Intel will release a new version of its Pentium M Processor, which is
the thin, light, and powerful Centrino-based notebook computers use.
The processor will start at 1.8GHz and will include 2MB of L2 cache,
compared with 1MB of L2 cache on the current 1.7GHz processor.
Generally, you find this size cache only on high-end workstation and
server chips such as Intel's Xeon processor. The Pentium M Processor
will hit speeds of 1.9GHz and 2.0GHz in early 2004, and Intel will
ship low-voltage and ultra-low-voltage versions of the chip at 1.3GHz,
1.2GHz, and 1.1GHz in late 2003. Manufacturers will use these chips in
the smallest and lightest portables.






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++] Some interesting news

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

Well I consider this interesting both for the developers and users in the
list so I post it:

From WinInfo UPDATE:


AMD Athlon 64 Set for September Release

   AMD inadvertently revealed this week through a leaked press release
that systems based on its 64-bit AMD Athlon 64 processor will ship
September 22. But that's not all: AMD is also shipping a special
version of the chip, the AMD Athlon 64-M, for use in notebook
computers. Like Apple's Power Mac G5 system, PCs based on the AMD
Athlon 64 and AMD Athlon 64-M can run 32-bit software full speed but
also take advantage of the vast 64-bit memory address space, opening
up new opportunities in scientific computing, database work, and other
high-end applications. But AMD isn't all about high-end, niche
computing. The company is hoping that manufacturers will add special
code to their games, video-editing products, and other
consumer-oriented software to make them run better on 64-bit systems.
AMD's high-end 64-bit chip, the AMD Opteron, is aimed at workstations
and servers and will debut in August.






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

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

> -----Original Message-----
> From: dev...@li...=20
> [mailto:dev...@li...] On Behalf=20
> Of Hossein Haeri
> Sent: Saturday, July 12, 2003 11:39 PM
> To: dev...@li...
> Subject: RE: [Dev-C++] STL Map question
>=20
>=20
> Dear Ioannis,
>=20
> I have just posted a response of this message to Shane, but
> unfortunately I haven't set the header to have a Cc for the Dev-Cpp
> Users. There, I have mentioned that your following assertion is most
> likely to be wrong. Anyway, I will repeat it one time more to make it
> clear to the group.
>=20
> > Eh? Why? Both have the same speed, actually empty is usually=20
> >=20
> > // inside the class definition
> > bool empty() const {  return size()=3D=3D0; }
>=20
> This can be the case, but that isn't always true.
>=20
> I know that holds for many of STL platforms, but they do not have to
> follow that way.


Yes. Any implementor can follow his way, the standard defines only the
template interface but the above is a reasonable implementation. And I =
got
it straight  from TC++PL 3. :-)



>=20
> > since map has to keep track of its size.=20
>=20
> Has it? No, I don't think so! But I will be pleased if you can prove
> me your assertion by mentioning its address in Standard. I don't think
> that beeing the case, as I have found the followings in the STL Bible,
> i.e., Generic Programming and the STL:
>=20
> "size() is linear in container's size. (For many containers, such as
> vector, and deque, size() is O(1). This satisfies the requirement that
> it be O(n).)
>=20
> maz_size() and empty() are amortised constant time."



It is not required by the standard but it would be prudent to not =
calculate
size() every time it is called. Also if I would have a choice between
storing information on whether it is empty or the size I would have =
chosen
the size since the empty can be estimated by the size and would require =
less
checks in the instance of the code where I would have placed a lot of =
checks
if the empty value is true or false and change it.

Anyway as I said only the interface is required by the standard but in =
C++
world all strive for maximum performance.



=20
> (If you want me to address the citation precisely, it is in Section
> 9.1.1, i.e., Container. And the complete bibliography is:
>=20
> Matthew H. Austern, Generic Programming and the STL: Using and
> Extending the C++ Standard Template Library, Addisson Wesley, 1999,
> ISBN: 0-201-30956-4.)
>=20
> These lines make me to become more sure that there isn't any guarantee
> in the Standard for size() and empty() to be equal in the sense of
> runtime.



Of course there is not. Nor there is any guarantee on which is faster =
nor
whether it takes milliseconds, seconds and weeks. However as I said what =
I
provided is a reasonable implementation.



>=20
> > In any case consider them as equal
> > (an equality comparison doesn't take time!).
>=20
> I don't know anything about the STL platform beeing used. But even if
> the Standard has mentioned that O(empty()) =3D=3D O(size()), that =
platform
> may not be Standard-compliant. Therefore, size() may be a calculating
> member function, meaning that it may compute the size and hence not be
> constant time.


Yes. It may also calculate the 1000 first digits of pi (3.14..) in the
meantime, but we are discussing reasonable implementations and having to
calculate the size() of every container that provides size() each time =
it is
called (and it may have millions) doesn't sound too reaaonable to me.


> But empty() is more likely to be just returning the
> state of an internal flag. And that's why I mentioned to choose
> empty() instead of size(). Because, the platform may well have
> considered to compute the size of map every time size() is invoked.


Yes, it may has decided manyy things. However we mau assume that all =
member
functions are maximally efficient, else throw the platform away!



> And that beeing the case, there may be some (offencing) optimisations
> the platform have chosen, and those are causing some unexpected
> exception or memory invalidation that the platform itself, doesn't
> know.

?!



> You may still think that there empty() and size() have the same
> runtime. But that doesn't mean there are equal in any case. If you
> have any doubt on this issue, consider Item 4 of Effective STL.


Read TC++PL 3. Straight from the creator of C++.






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

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

Daniel K. O. wrote:
> 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. :)

g++ "itself" is not bloated. I mean, it doesn't make bloated code, but 
the use of it's STL or something tends to make huge exes. Even if you 
make a really huge project, without iostream (just stdio.h and stuff), 
the result can still be small, however if you make even the smallest 
program, BUT you use iostream, then you get huge exe. This is really 
weird indeed, but that's what we have to live with.

--
Greetings,
   Balázs

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

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

Dear Ioannis,

I have just posted a response of this message to Shane, but
unfortunately I haven't set the header to have a Cc for the Dev-Cpp
Users. There, I have mentioned that your following assertion is most
likely to be wrong. Anyway, I will repeat it one time more to make it
clear to the group.

> Eh? Why? Both have the same speed, actually empty is usually 
> 
> // inside the class definition
> bool empty() const {  return size()==0; }

This can be the case, but that isn't always true.

I know that holds for many of STL platforms, but they do not have to
follow that way.

> since map has to keep track of its size. 

Has it? No, I don't think so! But I will be pleased if you can prove
me your assertion by mentioning its address in Standard. I don't think
that beeing the case, as I have found the followings in the STL Bible,
i.e., Generic Programming and the STL:

"size() is linear in container's size. (For many containers, such as
vector, and deque, size() is O(1). This satisfies the requirement that
it be O(n).)

maz_size() and empty() are amortised constant time."

(If you want me to address the citation precisely, it is in Section
9.1.1, i.e., Container. And the complete bibliography is:

Matthew H. Austern, Generic Programming and the STL: Using and
Extending the C++ Standard Template Library, Addisson Wesley, 1999,
ISBN: 0-201-30956-4.)

These lines make me to become more sure that there isn't any guarantee
in the Standard for size() and empty() to be equal in the sense of
runtime.

> In any case consider them as equal
> (an equality comparison doesn't take time!).

I don't know anything about the STL platform beeing used. But even if
the Standard has mentioned that O(empty()) == O(size()), that platform
may not be Standard-compliant. Therefore, size() may be a calculating
member function, meaning that it may compute the size and hence not be
constant time. But empty() is more likely to be just returning the
state of an internal flag. And that's why I mentioned to choose
empty() instead of size(). Because, the platform may well have
considered to compute the size of map every time size() is invoked.
And that beeing the case, there may be some (offencing) optimisations
the platform have chosen, and those are causing some unexpected
exception or memory invalidation that the platform itself, doesn't
know.

You may still think that there empty() and size() have the same
runtime. But that doesn't mean there are equal in any case. If you
have any doubt on this issue, consider Item 4 of Effective STL.

(Scott Meyers, Effective STL: 50 Specific Ways to Improve Your Use of
the Standard Template Library, Addison-Wesley, 2001, 
ISBN: 0-201-74962-9.)

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