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

[Dev-C++] Drawing lines

[<Dx 8a> <vin...@ed...>]

In DirectX's DirectDraw, how do I draw a straight line from Point A having coordinates (x1,y1) to point B with coordinates (x2,y2). is there a specific function for this operation?

Thanks

__________________________________
www.edsamail.com

Re: [Dev-C++] Damn floats

[Jason H. <jas...@bt...>]

Relying on type conversions to crop a number to a specific number of decimal
places isn't the best way of going about it, although it is usualy quite
effective. There are some mathematical functions for dealing with rounding
and integer values, and the one I suggest you look at is abs(), or fabs().
abs() is an overloaded function available in C++ whereas fabs() is
specificaly for float values (it actualy uses a double). You may already
know this, but multiplying by a power of ten before apply abs and then
dividing by that value again will allow you to choose to how many decimal
places you want to work. Adding .5 after the multiplication will ensure
proper rounding also.

The problem you are having with the lack of accuracy in the float is most
likely due to the inherant flaw in floating point representation. They
cannot represent all values in thier range dead on, and there will always be
a certain amount of rounding errors in some calculations. There's not a lot
you can do about it. There are different ways of representing numbers, but I
doubt you need that level of accuracy. What you can do with cout, or when
converting a number to a string is to set the number of decimal places it
will display, so the extra 0001 will be chopped off. For cout or other
stream operations I suggest you look at the precision() method. If you are
using sprintf then something like - sprintf(strarray, "%1.2f", my_float);
which should (I think) produce a number of at least 1 significant digit with
rounding to 2 decimal places. Experiment with it a little to see what
produces the results you want.

Jason.

Disclaimer: This information is meant as a guide, and may not be interpreted
as gospel truth. I try to reasonably, but not overly, accurate.


----- Original Message -----
From: "Brian McCall" <str...@ho...>
To: <dev...@li...>
Sent: Wednesday, October 31, 2001 2:19 AM
Subject: [Dev-C++] Damn floats


> I'm having much trouble trying to manipulate floats.  I try to truncate
the
> part left of the decimal like so:
>
> float num1 = 45.34;
> int num2 = int (num1);
> num1 -= float (num2);
>
> But when I display num1 (cout<<num1), I get something like 0.3400001.
> What am I supposed to do about this?
>
> Actually, the reason I am doing this is as part of a function that assigns
a
> float to a string, i.e., storing num1 in something like strNum1 as "45.34"
> (apstring strNum1; strNum1 = num1).
>
> Any ideas on either of these two problems?
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
>
>
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users

RE: [Dev-C++] Damn floats

[Ioannis V. <no...@ya...>]

> -----Original Message-----
> From: dev...@li...=20
> [mailto:dev...@li...] On Behalf=20
> Of Brian McCall
> Sent: Wednesday, October 31, 2001 4:20 AM
> To: dev...@li...
> Subject: [Dev-C++] Damn floats
>=20
>=20
> I'm having much trouble trying to manipulate floats.  I try=20
> to truncate the=20
> part left of the decimal like so:
>=20
> float num1 =3D 45.34;
> int num2 =3D int (num1);

The first cast is not needed.

> num1 -=3D float (num2);

The second cast also is not needed. These are built in type conversions.


>=20
> But when I display num1 (cout<<num1), I get something like=20
> 0.3400001. What am I supposed to do about this?

num1 is a float. So you display it as a float. only if you cast it as an
int you will get an int.
But the style of casting you use is the worst. Type1(x) or (Type1)x
(C-style) are equivallent and the worst. Normally in your case you can
output the int part by using an int. however if you just play with these
things the most safe is:


#include <iostream>

int main()
{
 using std::cout;
 using std::endl;
=20
 float f=3D0.2;
=20
 cout<<static_cast<int>(f)<<endl;
}


However try to *never* use casting in C++ (in contrast with C).


> Actually, the reason I am doing this is as part of a function=20
> that assigns a=20
> float to a string, i.e., storing num1 in something like=20
> strNum1 as "45.34"=20
> (apstring strNum1; strNum1 =3D num1).
>=20
> Any ideas on either of these two problems?

If you wantt to create that function don't bother, you have got
sprintf().

char s[200];
sprintf(s, "%f", 4.4);
string sf=3Ds;



Ioannis

* Ioannis Vranos
* Programming pages: http://www.noicys.f2s.com
* Alternative URL: http://run.to/noicys

[Dev-C++] Damn floats

[Brian M. <str...@ho...>]

I'm having much trouble trying to manipulate floats.  I try to truncate the 
part left of the decimal like so:

float num1 = 45.34;
int num2 = int (num1);
num1 -= float (num2);

But when I display num1 (cout<<num1), I get something like 0.3400001.
What am I supposed to do about this?

Actually, the reason I am doing this is as part of a function that assigns a 
float to a string, i.e., storing num1 in something like strNum1 as "45.34" 
(apstring strNum1; strNum1 = num1).

Any ideas on either of these two problems?

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

[Dev-C++] Compilation failed!!!

[<se...@ai...>]

Hi list=2E I try to compile an *=2Ec file and I haven=B4t got errors but =
in =

the =22compiler and linker output=22 (DEV-C++ 4) appear a lot of messages=
 =

like this=3A
=22C=3A=5CTEMP=5Cccbhaaaa=2Eo(=2Etext+0x1b)=3Aclient=2Ec=3A undefined ref=
erence to =

=60v3SignalRegister=27=22 Anybody can help me=3F The varaible are declara=
ted and =

I don=B4t know why appear this message=2E Thanks for all!!!!


Fdo=3A Dave
     =



=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
 Te gustan las carreras de coches=3F Tu pel=EDcula es The Fast and the =

furious (a todo gas)=2E =

 Airtel Vodafone te la trae y sortea un viaje a Los Angeles para dos =

personas y un curso de conducci=F3n deportiva=2E Te interesa=3F Ven a =

http=3A//www=2Eqtal=2Ecom

[Dev-C++] Newbee Q: Using other librarys in DEV++

[Lars-Bo J. <la...@sj...>]

Hi all

I am pretty new to C++ and totally new to DEV++, but it seems like a great
development platform. But I have a problem if have some programs that I did
with the cygwin package using the GNU cgicc library. It was easy to compile
that library for use with cygwin, but how can I compile the library for use
with DEV++ ? can it be done at all ?. 

I tried to configure DEV++ to use my Cygwin package but the specification of
the various paths does not comply with the newest cygwin package
(c:\Dev-c++\Mingw and Cygwin.txt).

Any help will be appreciated.

Lars-Bo

 
________________________________________________
Lars-Bo Jacobsen, Researcher M.Sc. ( Economics) 
Danish Institute of Agricultural and Fisheries Economics
Phone:  +45 35 28 68 00 (direct: +45 35 28 68 57)
Fax:      +45 35 28 68 01

[Dev-C++] test, ignore

[Lars-Bo J. <la...@sj...>]

________________________________________________
Lars-Bo Jacobsen, Researcher M.Sc. ( Economics) 
Danish Institute of Agricultural and Fisheries Economics
Phone:  +45 35 28 68 00 (direct: +45 35 28 68 57)
Fax:      +45 35 28 68 01

[Dev-C++] transparent window

[Christiaan S. <ck...@ia...>]

How can I make a transparent window? Ive tried setting the =
WS_EX_TRANSPARENT style for a window but that just makes its initial =
state transparent (if you move it the background moves with it)

RE: [Dev-C++] untitled1.o no such file or directory

[Ioannis V. <no...@ya...>]

Nothing is included by default.
=20
=20
Ioannis
=20
* Ioannis Vranos
* Programming pages: http://www.noicys.f2s.com
<http://www.noicys.f2s.com/>=20
* Alternative URL: http://run.to/noicys

-----Original Message-----
From: dev...@li...
[mailto:dev...@li...] On Behalf Of
Christiaan Scholtz
Sent: Sunday, October 28, 2001 12:06 AM
To: dev...@li...
Subject: [Dev-C++] untitled1.o no such file or directory


I figured out why free wasnt working. I hadnt included stdlib.h. Isnt it
supposed to be included by default though?

[Dev-C++] untitled1.o no such file or directory

[Christiaan S. <ck...@ia...>]

I figured out why free wasnt working. I hadnt included stdlib.h. Isnt it =
supposed to be included by default though?

[Dev-C++] (no subject)

[Christiaan S. <ck...@ia...>]

Ok I now think that that other linker error was as a result of this
compiling error:

c:\my documents\untitled1.cpp: In function `int LoadGLTextures()':

c:\my documents\untitled1.cpp:78: implicit declaration of function `int
free(...)'

Whats wrong with using the free function?

[Dev-C++] glaux.dll not found

[Christiaan S. <ck...@ia...>]

I found it

[Dev-C++] glaux.dll not found

[Christiaan S. <ck...@ia...>]

I get this error when trying to compile some code.I read in some posts =
that glaux is not supported anymore but that when this guy downloaded a =
glaux.dll from the net and put it in his system folder that it worked =
fine. I am having a hard time finding this file... can anyone help?

[Dev-C++] Editor questions

[Jack Y. <jy...@tw...>]

Hello,

I just started using Dev-C++.  The included editor doesn't seem to have any
keyboard shortcuts for manipulating the text (like block moves).  I was
wondering if it does and I am just not seeing it?  Or, is there another
editor that is preferred?

Jack
-- 
E-Mail: jy...@tw...
Alt:        jyork@voyager,net
Home:  http://my.voyager.net/~jyork

RE: [Dev-C++] opengl in dev-c++?

[Ioannis V. <no...@ya...>]

Ehehe, never mind what you did was an accomplishment. :)
 
 
Ioannis
 
* Ioannis Vranos
* Programming pages: http://www.noicys.f2s.com
<http://www.noicys.f2s.com/> 
* Alternative URL: http://run.to/noicys

-----Original Message-----
From: dev...@li...
[mailto:dev...@li...] On Behalf Of
Christiaan Scholtz
Sent: Friday, October 26, 2001 6:50 PM
To: dev...@li...
Subject: [Dev-C++] opengl in dev-c++?


Urgh its already in the faq all along! stoopid me!! urgh....

[Dev-C++] opengl in dev-c++?

[Christiaan S. <ck...@ia...>]

Urgh its already in the faq all along! stoopid me!! urgh....

[Dev-C++] opengl in dev-c++?

[Christiaan S. <ck...@ia...>]

I figured it all out! Whooohoo! Im am so proud of myself :-) I think  =
this all should be added to the dev-c++ faq... how do i do that?

What I did was I added "-lopengl32 -lglu32" as compiler options to the =
project and then everything compiled just fine! I also replaced =
CDS_FULLSCREEN with 0

[Dev-C++] opengl in dev-c++?

[Christiaan S. <ck...@ia...>]

I found that if I say File>New Project>Graphics>OpenGl template and paste my
code in that almost all of the opengl code works. This I think is becuase
"-lopengl32" is being added ass a compiler option. I still get this linker
error though:
c:\dev-c++\untitled1.o(.text+0x84):untitled1.cpp: undefined reference to
`gluPerspective@32'


Can anyone help?

RE: [Dev-C++] Discussion about C/C++ details

[Ioannis V. <no...@ya...>]

That web site book ratings are made by real C/C++ pros and they are
neutral. That site is recommended by Stroustrup. For the books i have, i
totally agree with their ratings. Schildt is read by a lot of people
(even some friends of mine) but thank God i had read about him before i
decide what book to buy. I have taken  some look on some of his comments
and surely he says a lot of inaccuracies (wrong things). If i had any of
his books i would throw it away. Of course this is only my opinion and i
do not suggest anyone about anything concerning his books (to be legally
secure).
=20
=20
Ioannis
=20
* Ioannis Vranos
* Programming pages: http://www.noicys.f2s.com
<http://www.noicys.f2s.com/>=20
* Alternative URL: http://run.to/noicys

-----Original Message-----
From: Jason Hardman [mailto:jas...@bt...]=20
Sent: Friday, October 26, 2001 5:28 PM
To: Ioannis Vranos
Subject: Re: [Dev-C++] Discussion about C/C++ details


an array rather than an index.
=20
That website certainly doesn't like Herbert Schilt do they? I'm not
going to argue about the relative merits of different authors. I still
use The Complete Reference books I have and that is what they are used
as, references. I'm not familiar with every nuance of C/C++ and so when
I answer a question posted on this site I am generally refering to at
least one of my books to check syntax, validity and context.
=20
Jason.

RE: [Dev-C++] Discussion about C/C++ details

[Ioannis V. <no...@ya...>]

Are you sure you have all optimizations on? We agree only at the last
result. I can't understand how memset() takes more than the for loop. As
for the case of length it is surely compiler defect. Standard library
operations are always expected to be at least as fast as our equivalents
(and since compiler can be more low level). strlen() case here is
unacceptable. About memset() latency probably it has to do with the
operating system, probably that your swap file is being used. Try to
reduce the string. It has nothing to do that the memory has been just
assigned.
=20
Anyway as you see strcat() outperforms our high level portable character
by character search. And if you want to see pure performance results,
since you have few memory close all running applications before
executing.
=20
About the operation ++x versus x++ for BUILT IN types, there is no value
returned if they are used stand alone. If they are assigned at the first
an increase is performed and then it is assigned, at the second it is
assigned and then it is increased which means the same performance.
=20
For custom classes operator++() and operator++(int) *have* difference in
performance when they are performed stand alone because they are
*functions* and we define them the first to increment the value and then
return the value and the second usually to create a copy of the existing
value, then increment the normal value and return the copy which takes
more time and space than the first. And these if we define them to
behave as the operators of built in types do (and this is what we must
do).=20
=20
At my first C times i was feeling very cool to use pointer arithmetic
and travel across even multidimensional arrays as if they were single
dimensional, or cast a pointer to a function to char *  and putchar()
its guts to the screen under dos, but the performance is the same. In
summary the postfix and prefix operator performance differences for
built in types is a myth and it applies only (and *usually*) for our
classes. Also the difference in performance between pointer arithmetic
and array indexing for built in types is also a myth and may apply only
for our classes if we define our iterators to behave different than
operator []. In case for C++ standard library there *must* be no
difference too.
=20
=20
Ioannis
=20
* Ioannis Vranos
* Programming pages: http://www.noicys.f2s.com
<http://www.noicys.f2s.com/>=20
* Alternative URL: http://run.to/noicys
=20

-----Original Message-----
From: Jason Hardman [mailto:jas...@bt...]=20
Sent: Friday, October 26, 2001 5:28 PM
To: Ioannis Vranos
Subject: Re: [Dev-C++] Discussion about C/C++ details


My machine is a PIII 750MHz, 128Mb RAM, so we are bound to have some
performance differences. The results I got were:
=20
Time spent for memset(): 770
Time spent for the for loop: 440
=20
strcat() needed: 330
Our manual strcat character by character thing needed: 390
=20
The size of our string was: 63999992
strlen() needed to measure the string length: 660
The time we needed to measure the length of the string: 380
=20
Some of the differences can be accounted for my the loading of my
machine. I've not gone to the trouble of shutting down all the
background tasks before running this test. The length taken for the
memset is probably because the memory had only just been assigned.
=20
The reason that I recommend the pre form over the post form in increment
and decrement operators is because of a discussion on a newsgroup I once
read. The gist of it was that when using a post form, a copy of the
original value is made before it is modified, and the copy is returned
as the result of the operator. I don't know if it's still true in modern
compilers. This copy will be discarded if it isn't assigned to anything
and so is a waste. Part of the argument was that the name C++ is
misleading and it really should be ++C if you wanted to follow a good
programming practice. :)
=20
As for pointer arithmetic, that was about something I was taught when
leaning C. It seems to be no longer true now, but I still like to use a
pointer to traverse an array rather than an index.
=20
That website certainly doesn't like Herbert Schilt do they? I'm not
going to argue about the relative merits of different authors. I still
use The Complete Reference books I have and that is what they are used
as, references. I'm not familiar with every nuance of C/C++ and so when
I answer a question posted on this site I am generally refering to at
least one of my books to check syntax, validity and context.
=20
Jason.

----- Original Message -----=20
From: Ioannis Vranos <mailto:no...@ya...> =20
To: Dev-C++ <mailto:dev...@li...> =20
Sent: Friday, October 26, 2001 1:01 PM
Subject: [Dev-C++] Discussion about C/C++ details


At first the results of your code to my pc (piii 1000 MHz, 512 MB RAM):
=20
Time spent for memset(): 200
Time spent for the for loop: 350
=20
strcat() needed: 290
Our manual strcat character by character thing needed: 340
=20
The size of our string was: 63999992
strlen() needed to measure the string length: 481
The time we needed to measure the length of the string: 340
=20
=20
I hadn't thought that the compiler excludes the call and assignment of
i=3Dstrlen() because it notices we do not use i (clever indeed).  But =
the
rest shows clearly that memset() is not using character by character
assignment to assign values and strcat is not looking character after
character too (perhaps they use an int pointer and make tricks,
something i just thought but not character after character).=20
=20
=20
It seems that we will never end arguing on details. I disagree with your
comment:
=20
/* When using increment or decrement operators you should use the pre
form
    rather than the post form as it is more efficient. Only post
increment or
    decrement when you need the value before the change.
    Also pointer arithmetic is faster than array indexing. */
=20
=20
This is truth *only* if we use overloaded post increment and decrement
operators for our objects and not for built in types. This thing reminds
me something i read on the web from a Schildt book, i will not tell you
about Schildt, check www.accu.org at the book reviews and read the
reviews of his books.=20
Also pointer arithmetic and array indexing is exactly the same and
compiler translates them the same. So this is definately wrong too. :)
=20
=20
I changed the color so as to find quickly my disagreements. :)
=20
=20
=20
Ioannis
=20

* Ioannis Vranos
* Programming pages: http://www.noicys.f2s.com
<http://www.noicys.f2s.com/>=20
* Alternative URL: http://run.to/noicys
=20

-----Original Message-----
From: dev...@li...
[mailto:dev...@li...] On Behalf Of Jason
Hardman
Sent: Friday, October 26, 2001 3:31 AM
To: Dev-C++
Subject: Re: [Dev-C++] Errorhandling


I'm sure you want this over and done with, but I decided to look at your
code and I have optimised some of it, and corrected an error that cause
a miss read of the time taken for strlen(). I hadn't realised this, but
when you are assigning a variable a value you don't use the compiler
happily ignores the value and doesn't bother with the assignment. What
that meant was it didn't actualy execute the strlen function in your
version, hence no time taken. I hadn't known this before, but it's quite
clever.
=20
I also did some other optimisations, I note that strcat() is still
slightly faster than our own version, but not by a massive margin. I'm
not absolutley sure that the tests are equal, but they seem to be
representative. I find it funny that my "memset" is faster than the real
one, so maybe there's an error or unaccounted optimisation somewhere?
=20
Note that I did the test using full compiler optimisations, as that
would be representative of a real world test. Also note that I decreased
SIZE, because I have only 128MB on my machine and using a 100 million
bytes forces windows to use virtual memory, which will cause large
slowdown, and prevent accurate figures.
=20
I was tempted to rewrite it all into a style I would normally use, but
couldn't be bothered. :-D
=20
Regards, Jason.

----- Original Message -----=20
From: Ioannis  <mailto:no...@ya...> Vranos=20
To: Dev-C++ <mailto:dev...@li...> =20
Sent: Friday, October 26, 2001 1:02 AM
Subject: RE: [Dev-C++] Errorhandling

Ok, we all agree that it is working like that but i am probably right on
this (as you were right for some other details in things i had not
noticed before).
=20
But my last effort to persuade you is attached in this email as file
temp.c . It is ANSI C code and it shows the differences between the
performance of standard library functions and character by character
things. Please take a look and execute the code.
=20
=20
The results to my machine:
=20
C:\c>temp
Time spent for memset(): 300
Time spent for the for loop: 471
=20
strcat() needed: 461
Our manual strcat character by character thing needed: 571
=20
strlen() needed to measure the string length: 0
The time we needed to measure the length of the string: 560
=20
=20
Notice especially the last.
=20
=20
Friendly,
Ioannis
=20

* Ioannis Vranos
* Programming pages: http://www.noicys.f2s.com
<http://www.noicys.f2s.com/>=20
* Alternative URL: http://run.to/noicys
=20
=20

-----Original Message-----
From: dev...@li...
[mailto:dev...@li...] On Behalf Of Jason
Hardman
Sent: Friday, October 26, 2001 12:05 AM
To: Dev-C++
Subject: Re: [Dev-C++] Errorhandling


You cannot always know the length of an array or string at compile time.
It is possible for things like array size and such to be determined at
compile-time and at run-time (depending), but by doing it at run-time
you are incurring an overhead in your code, which isn't part of the C
style of programming. Adding these mechanisms to C code with hidden
compiler features would be breaking the general C/C++ ethic, at least in
my view.
=20
The only reason I'm 'discussing' this is because the more I think about
it the more I come to believe that it's more likely that standard
functions like strcat() and strlen() will determine the length of the
string by going all the way through the string until null. I know this
is an old argument, but I find it difficult to believe that it would be
done a different way. C doesn't actualy have native support for strings,
it just uses an array of chars, and allows the definition of string
literals.
=20
In Pascal, for example, it does have native support for strings and you
will find that it will store a pointer to an array and the first element
of the array will be the length of the string that follows.
=20
If you want we can end this particular argument and settle on the fact
that we are both willing to differ in opinion, and that it doesn't
matter which is true 'cos it still works no matter what.
=20
Jason.

[Dev-C++] opengl in dev-c++?

[Christiaan S. <ck...@ia...>]

I changed CDS_FULLSCREEN  to 0 as jason suggested and now I dont get a error
about it anymore but I do get these errors:

The code that this applies to is attached.

C:\WINDOWS\TEMP\ccNmdcgb.o(.text+0x38):lesson1.cpp: undefined reference to
`glViewport@16'

C:\WINDOWS\TEMP\ccNmdcgb.o(.text+0x45):lesson1.cpp: undefined reference to
`glMatrixMode@4'

C:\WINDOWS\TEMP\ccNmdcgb.o(.text+0x4d):lesson1.cpp: undefined reference to
`glLoadIdentity@0'

C:\WINDOWS\TEMP\ccNmdcgb.o(.text+0x84):lesson1.cpp: undefined reference to
`gluPerspective@32'

C:\WINDOWS\TEMP\ccNmdcgb.o(.text+0x91):lesson1.cpp: undefined reference to
`glMatrixMode@4'

C:\WINDOWS\TEMP\ccNmdcgb.o(.text+0x99):lesson1.cpp: undefined reference to
`glLoadIdentity@0'

C:\WINDOWS\TEMP\ccNmdcgb.o(.text+0xb7):lesson1.cpp: undefined reference to
`glShadeModel@4'

C:\WINDOWS\TEMP\ccNmdcgb.o(.text+0xd1):lesson1.cpp: undefined reference to
`glClearColor@16'

C:\WINDOWS\TEMP\ccNmdcgb.o(.text+0xe0):lesson1.cpp: undefined reference to
`glClearDepth@8'

C:\WINDOWS\TEMP\ccNmdcgb.o(.text+0xf0):lesson1.cpp: undefined reference to
`glEnable@4'

C:\WINDOWS\TEMP\ccNmdcgb.o(.text+0x100):lesson1.cpp: undefined reference to
`glDepthFunc@4'

C:\WINDOWS\TEMP\ccNmdcgb.o(.text+0x115):lesson1.cpp: undefined reference to
`glHint@8'

C:\WINDOWS\TEMP\ccNmdcgb.o(.text+0x13b):lesson1.cpp: undefined reference to
`glClear@4'

C:\WINDOWS\TEMP\ccNmdcgb.o(.text+0x143):lesson1.cpp: undefined reference to
`glLoadIdentity@0'

C:\WINDOWS\TEMP\ccNmdcgb.o(.text+0x258):lesson1.cpp: undefined reference to
`wglMakeCurrent@8'

C:\WINDOWS\TEMP\ccNmdcgb.o(.text+0x282):lesson1.cpp: undefined reference to
`wglDeleteContext@4'

C:\WINDOWS\TEMP\ccNmdcgb.o(.text+0x8ce):lesson1.cpp: undefined reference to
`wglCreateContext@4'

C:\WINDOWS\TEMP\ccNmdcgb.o(.text+0x914):lesson1.cpp: undefined reference to
`wglMakeCurrent@8'

Re: [Dev-C++] Problem with Allegro Version 3.9.39 (WIP)

[Elias P. <eli...@ao...>]

> When me try compile Allegro, error is:
> 
> Compiling Allegro for MINGW32, debugging. Please wait...
> gcc -DALLEGRO_STATICLINK  -DALLEGRO_SRC -DDEBUGMODE=1 -Wall -Wno-unused  -g -I.
> -I./include -o obj/mingw32/alld_s/wddaccel.o -c src/win/wddaccel.c
> In file included from src/win/wddaccel.c:23:
> src\win\wddraw.h:29: ddraw.h: No such file or directory
> make: *** [obj/mingw32/alld_s/wddaccel.o] Error 1
> 
> I have Dev-C++ 4.01
> 
> HELP!

You don't have the DirectX headers installed correctly. See
the file "readme.mgw", which should be in your allegro directory,
for details. You might find more information at allegro.cc
(http://www.allegro.cc/ubb-bin/ultimatebb.cgi?ubb=get_topic&f=10&t=000083)
and in the allegro mailing lists. (http://alleg.sf.net)

--
Elias Pschernig

[Dev-C++] Problem with Allegro Version 3.9.39 (WIP)

[Ivan J. <iva...@vi...>]

V2hlbiBtZSB0cnkgY29tcGlsZSBBbGxlZ3JvLCBlcnJvciBpczoNCg0KQ29tcGlsaW5nIEFsbGVn
cm8gZm9yIE1JTkdXMzIsIGRlYnVnZ2luZy4gUGxlYXNlIHdhaXQuLi4NCmdjYyAtREFMTEVHUk9f
U1RBVElDTElOSyAgLURBTExFR1JPX1NSQyAtRERFQlVHTU9ERT0xIC1XYWxsIC1Xbm8tdW51c2Vk
ICAtZyAtSS4NCi1JLi9pbmNsdWRlIC1vIG9iai9taW5ndzMyL2FsbGRfcy93ZGRhY2NlbC5vIC1j
IHNyYy93aW4vd2RkYWNjZWwuYw0KSW4gZmlsZSBpbmNsdWRlZCBmcm9tIHNyYy93aW4vd2RkYWNj
ZWwuYzoyMzoNCnNyY1x3aW5cd2RkcmF3Lmg6Mjk6IGRkcmF3Lmg6IE5vIHN1Y2ggZmlsZSBvciBk
aXJlY3RvcnkNCm1ha2U6ICoqKiBbb2JqL21pbmd3MzIvYWxsZF9zL3dkZGFjY2VsLm9dIEVycm9y
IDENCg0KSSBoYXZlIERldi1DKysgNC4wMQ0KDQpIRUxQIQ0KDQpJdmFuIEp1cmlzaWMNCml2YW4u
anVyaXNpY0B2aXAuaHINCg0K

RE: [Dev-C++] Discussion about C/C++ details

[Ioannis V. <no...@ya...>]

And for our system they occupy the same space too, because
sizeof(size_t)=3D=3Dsizeof(char *)=3D=3Dsizeof(int)=3D=3D4
=20
=20
Ioannis
=20
* Ioannis Vranos
* Programming pages: http://www.noicys.f2s.com
<http://www.noicys.f2s.com/>=20
* Alternative URL: http://run.to/noicys

-----Original Message-----
From: Ioannis Vranos [mailto:no...@ya...]=20
Sent: Friday, October 26, 2001 2:12 PM
To: Dev-C++ (dev...@li...)
Subject: RE: [Dev-C++] Discussion about C/C++ details


A slight addition to clear things up: Also pointer arithmetic and array
indexing is exactly the same in terms of speed (the first occupies more
space) for built in types *only*. For overloaded operators in classes it
depends how we define them.
=20
So in general you seem to confuse the performance of overloaded
operators for custom classes and the performance of default operators
for built in types.
=20
=20
Ioannis
=20

* Ioannis Vranos
* Programming pages: http://www.noicys.f2s.com
<http://www.noicys.f2s.com/>=20
* Alternative URL: http://run.to/noicys
=20

Also pointer arithmetic and array indexing is exactly the same and
compiler translates them the same. So this is definately wrong too. :)
=20
=20
I changed the color so as to find quickly my disagreements. :)
=20
=20
=20
Ioannis
=20

* Ioannis Vranos
* Programming pages: http://www.noicys.f2s.com
<http://www.noicys.f2s.com/>=20
* Alternative URL: http://run.to/noicys
=20

-----Original Message-----
From: dev...@li...
[mailto:dev...@li...] On Behalf Of Jason
Hardman
Sent: Friday, October 26, 2001 3:31 AM
To: Dev-C++
Subject: Re: [Dev-C++] Errorhandling


I'm sure you want this over and done with, but I decided to look at your
code and I have optimised some of it, and corrected an error that cause
a miss read of the time taken for strlen(). I hadn't realised this, but
when you are assigning a variable a value you don't use the compiler
happily ignores the value and doesn't bother with the assignment. What
that meant was it didn't actualy execute the strlen function in your
version, hence no time taken. I hadn't known this before, but it's quite
clever.
=20
I also did some other optimisations, I note that strcat() is still
slightly faster than our own version, but not by a massive margin. I'm
not absolutley sure that the tests are equal, but they seem to be
representative. I find it funny that my "memset" is faster than the real
one, so maybe there's an error or unaccounted optimisation somewhere?
=20
Note that I did the test using full compiler optimisations, as that
would be representative of a real world test. Also note that I decreased
SIZE, because I have only 128MB on my machine and using a 100 million
bytes forces windows to use virtual memory, which will cause large
slowdown, and prevent accurate figures.
=20
I was tempted to rewrite it all into a style I would normally use, but
couldn't be bothered. :-D
=20
Regards, Jason.

----- Original Message -----=20
From: Ioannis  <mailto:no...@ya...> Vranos=20
To: Dev-C++ <mailto:dev...@li...> =20
Sent: Friday, October 26, 2001 1:02 AM
Subject: RE: [Dev-C++] Errorhandling

Ok, we all agree that it is working like that but i am probably right on
this (as you were right for some other details in things i had not
noticed before).
=20
But my last effort to persuade you is attached in this email as file
temp.c . It is ANSI C code and it shows the differences between the
performance of standard library functions and character by character
things. Please take a look and execute the code.
=20
=20
The results to my machine:
=20
C:\c>temp
Time spent for memset(): 300
Time spent for the for loop: 471
=20
strcat() needed: 461
Our manual strcat character by character thing needed: 571
=20
strlen() needed to measure the string length: 0
The time we needed to measure the length of the string: 560
=20
=20
Notice especially the last.
=20
=20
Friendly,
Ioannis
=20

* Ioannis Vranos
* Programming pages: http://www.noicys.f2s.com
<http://www.noicys.f2s.com/>=20
* Alternative URL: http://run.to/noicys
=20
=20

-----Original Message-----
From: dev...@li...
[mailto:dev...@li...] On Behalf Of Jason
Hardman
Sent: Friday, October 26, 2001 12:05 AM
To: Dev-C++
Subject: Re: [Dev-C++] Errorhandling


You cannot always know the length of an array or string at compile time.
It is possible for things like array size and such to be determined at
compile-time and at run-time (depending), but by doing it at run-time
you are incurring an overhead in your code, which isn't part of the C
style of programming. Adding these mechanisms to C code with hidden
compiler features would be breaking the general C/C++ ethic, at least in
my view.
=20
The only reason I'm 'discussing' this is because the more I think about
it the more I come to believe that it's more likely that standard
functions like strcat() and strlen() will determine the length of the
string by going all the way through the string until null. I know this
is an old argument, but I find it difficult to believe that it would be
done a different way. C doesn't actualy have native support for strings,
it just uses an array of chars, and allows the definition of string
literals.
=20
In Pascal, for example, it does have native support for strings and you
will find that it will store a pointer to an array and the first element
of the array will be the length of the string that follows.
=20
If you want we can end this particular argument and settle on the fact
that we are both willing to differ in opinion, and that it doesn't
matter which is true 'cos it still works no matter what.
=20
Jason.

RE: [Dev-C++] Discussion about C/C++ details

[Ioannis V. <no...@ya...>]

A slight addition to clear things up: Also pointer arithmetic and array
indexing is exactly the same in terms of speed (the first occupies more
space) for built in types *only*. For overloaded operators in classes it
depends how we define them.
=20
So in general you seem to confuse the performance of overloaded
operators for custom classes and the performance of default operators
for built in types.
=20
=20
Ioannis
=20
* Ioannis Vranos
* Programming pages: http://www.noicys.f2s.com
<http://www.noicys.f2s.com/>=20
* Alternative URL: http://run.to/noicys
=20

Also pointer arithmetic and array indexing is exactly the same and
compiler translates them the same. So this is definately wrong too. :)
=20
=20
I changed the color so as to find quickly my disagreements. :)
=20
=20
=20
Ioannis
=20

* Ioannis Vranos
* Programming pages: http://www.noicys.f2s.com
<http://www.noicys.f2s.com/>=20
* Alternative URL: http://run.to/noicys
=20

-----Original Message-----
From: dev...@li...
[mailto:dev...@li...] On Behalf Of Jason
Hardman
Sent: Friday, October 26, 2001 3:31 AM
To: Dev-C++
Subject: Re: [Dev-C++] Errorhandling


I'm sure you want this over and done with, but I decided to look at your
code and I have optimised some of it, and corrected an error that cause
a miss read of the time taken for strlen(). I hadn't realised this, but
when you are assigning a variable a value you don't use the compiler
happily ignores the value and doesn't bother with the assignment. What
that meant was it didn't actualy execute the strlen function in your
version, hence no time taken. I hadn't known this before, but it's quite
clever.
=20
I also did some other optimisations, I note that strcat() is still
slightly faster than our own version, but not by a massive margin. I'm
not absolutley sure that the tests are equal, but they seem to be
representative. I find it funny that my "memset" is faster than the real
one, so maybe there's an error or unaccounted optimisation somewhere?
=20
Note that I did the test using full compiler optimisations, as that
would be representative of a real world test. Also note that I decreased
SIZE, because I have only 128MB on my machine and using a 100 million
bytes forces windows to use virtual memory, which will cause large
slowdown, and prevent accurate figures.
=20
I was tempted to rewrite it all into a style I would normally use, but
couldn't be bothered. :-D
=20
Regards, Jason.

----- Original Message -----=20
From: Ioannis  <mailto:no...@ya...> Vranos=20
To: Dev-C++ <mailto:dev...@li...> =20
Sent: Friday, October 26, 2001 1:02 AM
Subject: RE: [Dev-C++] Errorhandling

Ok, we all agree that it is working like that but i am probably right on
this (as you were right for some other details in things i had not
noticed before).
=20
But my last effort to persuade you is attached in this email as file
temp.c . It is ANSI C code and it shows the differences between the
performance of standard library functions and character by character
things. Please take a look and execute the code.
=20
=20
The results to my machine:
=20
C:\c>temp
Time spent for memset(): 300
Time spent for the for loop: 471
=20
strcat() needed: 461
Our manual strcat character by character thing needed: 571
=20
strlen() needed to measure the string length: 0
The time we needed to measure the length of the string: 560
=20
=20
Notice especially the last.
=20
=20
Friendly,
Ioannis
=20

* Ioannis Vranos
* Programming pages: http://www.noicys.f2s.com
<http://www.noicys.f2s.com/>=20
* Alternative URL: http://run.to/noicys
=20
=20

-----Original Message-----
From: dev...@li...
[mailto:dev...@li...] On Behalf Of Jason
Hardman
Sent: Friday, October 26, 2001 12:05 AM
To: Dev-C++
Subject: Re: [Dev-C++] Errorhandling


You cannot always know the length of an array or string at compile time.
It is possible for things like array size and such to be determined at
compile-time and at run-time (depending), but by doing it at run-time
you are incurring an overhead in your code, which isn't part of the C
style of programming. Adding these mechanisms to C code with hidden
compiler features would be breaking the general C/C++ ethic, at least in
my view.
=20
The only reason I'm 'discussing' this is because the more I think about
it the more I come to believe that it's more likely that standard
functions like strcat() and strlen() will determine the length of the
string by going all the way through the string until null. I know this
is an old argument, but I find it difficult to believe that it would be
done a different way. C doesn't actualy have native support for strings,
it just uses an array of chars, and allows the definition of string
literals.
=20
In Pascal, for example, it does have native support for strings and you
will find that it will store a pointer to an array and the first element
of the array will be the length of the string that follows.
=20
If you want we can end this particular argument and settle on the fact
that we are both willing to differ in opinion, and that it doesn't
matter which is true 'cos it still works no matter what.
=20
Jason.