dev-cpp-users Mailing List for Dev-C++ (Page 2)

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?

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.

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.

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'

> 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

V2hlbiBtZSB0cnkgY29tcGlsZSBBbGxlZ3JvLCBlcnJvciBpczoNCg0KQ29tcGlsaW5nIEFsbGVn
cm8gZm9yIE1JTkdXMzIsIGRlYnVnZ2luZy4gUGxlYXNlIHdhaXQuLi4NCmdjYyAtREFMTEVHUk9f
U1RBVElDTElOSyAgLURBTExFR1JPX1NSQyAtRERFQlVHTU9ERT0xIC1XYWxsIC1Xbm8tdW51c2Vk
ICAtZyAtSS4NCi1JLi9pbmNsdWRlIC1vIG9iai9taW5ndzMyL2FsbGRfcy93ZGRhY2NlbC5vIC1j
IHNyYy93aW4vd2RkYWNjZWwuYw0KSW4gZmlsZSBpbmNsdWRlZCBmcm9tIHNyYy93aW4vd2RkYWNj
ZWwuYzoyMzoNCnNyY1x3aW5cd2RkcmF3Lmg6Mjk6IGRkcmF3Lmg6IE5vIHN1Y2ggZmlsZSBvciBk
aXJlY3RvcnkNCm1ha2U6ICoqKiBbb2JqL21pbmd3MzIvYWxsZF9zL3dkZGFjY2VsLm9dIEVycm9y
IDENCg0KSSBoYXZlIERldi1DKysgNC4wMQ0KDQpIRUxQIQ0KDQpJdmFuIEp1cmlzaWMNCml2YW4u
anVyaXNpY0B2aXAuaHINCg0K

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.

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.

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 Vranos <mailto:no...@ya...> =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.

I'm always glad to help, and it's nice to hear a "thank you" now and again.
:)

Jason.

----- Original Message -----
From: "Marton Rusk" <mar...@ho...>
To: <jas...@bt...>
Sent: Friday, October 26, 2001 4:21 AM
Subject: Re: [Dev-C++] newbie needs help


> WOW, yippeee! that fixed it, thank you! I been banging my head against the
> keyboard half the day trying to figure this out. I "thought" i put it
inside
> of main but i guess i didn't try it.
>
> Thank you!
>
> Marton D. Rusk
>
>
> >From: "Jason Hardman" <jas...@bt...>
> >To: "Dev-C++" <dev...@li...>
> >Subject: Re: [Dev-C++] newbie needs help
> >Date: Fri, 26 Oct 2001 04:09:25 +0100
> >
> >The commented code should be inside the main function, between the two
{}.
> >Also you need to qualify the scope of the flags in the first, so:
> >
> >cout << ios::fixed << ios::showpoint;
> >
> >Which will compile in Dev-C++, although I have noticed it outputs a weird
> >number, but I'll let you sort that out.
> >
> >The second commented code works fine (assuming you put it inside main()).
> >
> >The last won't work, but it's not needed as you should use ios:: and not
> >ios_base::
> >
> >I've attached some code for you to work with.
> >
> >Jason.
> >
> >----- Original Message -----
> >From: "Marton Rusk" <mar...@ho...>
> >To: <dev...@li...>
> >Sent: Friday, October 26, 2001 3:46 AM
> >Subject: [Dev-C++] newbie needs help
> >
> >
> > > Hello all,
> > >
> > > I'm a programming student currently in my C++ part 2 class.
> > >
> > > Please tell me why the following code gives me errors with any of the
> >three
> > > commented floating point formatting code un-commented? I get errors
with
> > > three different compilers.
> > >
> > > If anyone knows how to fix this please help. Or, if anyone knows
another
> >way
> > > to format floating point data please help.
> > >
> > > Thanks,
> > >
> > > Marton D. Rusk
> > >
> > >
> > > #include <iostream>
> > > #include <iomanip>
> > >
> > > using namespace std;
> > >
> > > //cout << fixed << showpoint; //don't work
> > >
> > > //cout.setf(ios::fixed, ios::floatfield); //don't work
> > > //cout.setf(ios::showpoint);
> > >
> > > //cout.setf(ios_base::fixed, ios_base::floatfield); //don't work
> > > //cout.setf(ios_base::showpoint);
> > >
> > > int main(){
> > >
> > > float number = 3.57890;
> > >
> > > cout << number;
> > > return 0;
> > > }
> > >
> > >
> > > _________________________________________________________________
> > > 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
> ><< iomanipstuff.cpp >>
>
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
>

The commented code should be inside the main function, between the two {}.
Also you need to qualify the scope of the flags in the first, so:

cout << ios::fixed << ios::showpoint;

Which will compile in Dev-C++, although I have noticed it outputs a weird
number, but I'll let you sort that out.

The second commented code works fine (assuming you put it inside main()).

The last won't work, but it's not needed as you should use ios:: and not
ios_base::

I've attached some code for you to work with.

Jason.

----- Original Message -----
From: "Marton Rusk" <mar...@ho...>
To: <dev...@li...>
Sent: Friday, October 26, 2001 3:46 AM
Subject: [Dev-C++] newbie needs help


> Hello all,
>
> I'm a programming student currently in my C++ part 2 class.
>
> Please tell me why the following code gives me errors with any of the
three
> commented floating point formatting code un-commented? I get errors with
> three different compilers.
>
> If anyone knows how to fix this please help. Or, if anyone knows another
way
> to format floating point data please help.
>
> Thanks,
>
> Marton D. Rusk
>
>
> #include <iostream>
> #include <iomanip>
>
> using namespace std;
>
> //cout << fixed << showpoint; //don't work
>
> //cout.setf(ios::fixed, ios::floatfield); //don't work
> //cout.setf(ios::showpoint);
>
> //cout.setf(ios_base::fixed, ios_base::floatfield); //don't work
> //cout.setf(ios_base::showpoint);
>
> int main(){
>
> float number = 3.57890;
>
> cout << number;
> return 0;
> }
>
>
> _________________________________________________________________
> 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

Hello all,

I'm a programming student currently in my C++ part 2 class.

Please tell me why the following code gives me errors with any of the three
commented floating point formatting code un-commented? I get errors with
three different compilers.

If anyone knows how to fix this please help. Or, if anyone knows another way
to format floating point data please help.

Thanks,

Marton D. Rusk


#include <iostream>
#include <iomanip>

using namespace std;

//cout << fixed << showpoint; //don't work

//cout.setf(ios::fixed, ios::floatfield); //don't work
//cout.setf(ios::showpoint);

//cout.setf(ios_base::fixed, ios_base::floatfield); //don't work
//cout.setf(ios_base::showpoint);

int main(){

float number = 3.57890;

cout << number;
return 0;
}


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

Hello all,

I'm a programming student currently in my C++ part 2 class.

Please tell me why the following code gives me errors with any of the three 
commented floating point formatting code un-commented? I get errors with 
three different compilers.

If anyone knows how to fix this please help. Or, if anyone knows another way 
to format floating point data please help.

Thanks,

Marton D. Rusk


#include <iostream>
#include <iomanip>

using namespace std;

//cout << fixed << showpoint; //don't work

//cout.setf(ios::fixed, ios::floatfield); //don't work
//cout.setf(ios::showpoint);

//cout.setf(ios_base::fixed, ios_base::floatfield); //don't work
//cout.setf(ios_base::showpoint);

int main(){

float number = 3.57890;

cout << number;
return 0;
}




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

Hello ,

  

-- 
Best regards,
 Andreas                          mailto:ex...@gm...

hi dev-cpp-users,

can anyone tell me, where i can find
a manual describing all the libraries included in devc

like memory.h, winsock.h, dos.h
  

-- 
MFG
Andreas Sauer                          mailto:ex...@gm...

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

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.

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.

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.

Jason.

----- Original Message -----=20
  From: Ioannis Vranos=20
  To: Dev-C++=20
  Sent: Thursday, October 25, 2001 10:54 PM
  Subject: RE: [Dev-C++] Errorhandling


  Isn't it possible for an internal "sizeof style" mechanism that =
determines the size of the data and insert it as a constant value in any =
function, at a specific system?



  Btw for what about are we arguing for? (If we are arguing) :)


  Ioannis

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

    -----Original Message-----
    From: dev...@li... =
[mailto:dev...@li...] On Behalf Of Jason =
Hardman
    Sent: Thursday, October 25, 2001 4:13 PM
    To: Dev-C++
    Subject: Re: [Dev-C++] Errorhandling


    > As a hint take for example
    > sizeof. sizeof even for ANSI standard knows the length of an array =
in
    > the scope it was defined. How does it know? It's compiler stuff =
and
    > compiler knows. So strcat() to search character after character =
would be
    > stupid for a nowadays compiler. But it is *safe* to assume it =
looks
    > character after character to find the '\0'.

    It's important to realise that sizeof is a special compile time =
operator. When the compiler finds it it determines the size of the data =
refered to and inserts it as a constant value. The sizeof operator won't =
work at runtime. For it to work at runtime the compiler would have to =
include a lot of extra code and information about a data type created to =
help detemine sizes, and that wouldn't follow the standard AFAICT. To do =
that would turn C/C++ into a higher level "safe" language that is also a =
lot slower. So what does strcat() or strlen() do when you pass it a =
dynamically allocated array that the compiler didn't know about at =
compile-time? It won't use the sizeof. =20


    > unsigned char str[] =3D {'\200', '\250', '\210', '\300', '\0'};
    >=20
    > I've not looked up what those numbers do, but generally there=20
    > are additional characters after 127 decimal (177 octal) that=20
    > are special, i.e. graphics characters. I remind you that a=20
    > backslash followed by a number is an octal number and not a =
decimal.

    > A number having a \ is an escape sequence, *not* an octal number. =
0200
    > is an octal number (without ' ').

    I was refering to the fact that the number following the backslash =
is interpreted as an octal constant and not as a decimal; it doesn't =
need the preceding zero. Also if you write '\xff', that is a hexadecimal =
character constant.

    Regards, Jason.

> I am having some trouble with compiling Allegro. Has anyone succeeded with
> this recently? Please post the steps you took to get it working.

There should be an extra section about dev-c++ in the readme.mgw file, IIRC.
Else, you might find this useful:

http://www.allegro.cc/ubb-bin/ultimatebb.cgi?ubb=get_topic&f=10&t=000083

--
Elias Pschernig

Ok Ive downloaded all these files:
gl.h glu.h glaux.h

 now how do i tell the compiler to use them? where should i copy them =
to?

I am having some trouble with compiling Allegro. Has anyone succeeded with
this recently? Please post the steps you took to get it working.

About '\some_number' and octal, you are right i checked so i recall the
last C style code. :)
=20
About the rest concerning compiler implementation and system dependend
(and some times in another language) code i insist. :)
=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: Thursday, October 25, 2001 4:13 PM
To: Dev-C++
Subject: Re: [Dev-C++] Errorhandling


> As a hint take for example
> sizeof. sizeof even for ANSI standard knows the length of an array in
> the scope it was defined. How does it know? It's compiler stuff and
> compiler knows. So strcat() to search character after character would
be
> stupid for a nowadays compiler. But it is *safe* to assume it looks
> character after character to find the '\0'.
=20
It's important to realise that sizeof is a special compile time
operator. When the compiler finds it it determines the size of the data
refered to and inserts it as a constant value. The sizeof operator won't
work at runtime. For it to work at runtime the compiler would have to
include a lot of extra code and information about a data type created to
help detemine sizes, and that wouldn't follow the standard AFAICT. To do
that would turn C/C++ into a higher level "safe" language that is also a
lot slower. So what does strcat() or strlen() do when you pass it a
dynamically allocated array that the compiler didn't know about at
compile-time? It won't use the sizeof. =20
=20

> unsigned char str[] =3D {'\200', '\250', '\210', '\300', '\0'};
>=20
> I've not looked up what those numbers do, but generally there=20
> are additional characters after 127 decimal (177 octal) that=20
> are special, i.e. graphics characters. I remind you that a=20
> backslash followed by a number is an octal number and not a decimal.

> A number having a \ is an escape sequence, *not* an octal number. 0200
> is an octal number (without ' ').
=20
I was refering to the fact that the number following the backslash is
interpreted as an octal constant and not as a decimal; it doesn't need
the preceding zero. Also if you write '\xff', that is a hexadecimal
character constant.
=20
Regards, Jason.

Isn't it possible for an internal "sizeof style" mechanism that
determines the size of the data and insert it as a constant value in any
function, at a specific system?
=20
=20
For the rest check the following C++ code:
=20
#include <cstdio>
=20
int main()
{
 using namespace std;
=20
 printf("%d %u\n\n", '\200', '\200');
 printf("%d %u\n", 0200, 0200);
}
=20
=20
Btw for what about are we arguing for? (If we are arguing) :)
=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: Thursday, October 25, 2001 4:13 PM
To: Dev-C++
Subject: Re: [Dev-C++] Errorhandling


> As a hint take for example
> sizeof. sizeof even for ANSI standard knows the length of an array in
> the scope it was defined. How does it know? It's compiler stuff and
> compiler knows. So strcat() to search character after character would
be
> stupid for a nowadays compiler. But it is *safe* to assume it looks
> character after character to find the '\0'.
=20
It's important to realise that sizeof is a special compile time
operator. When the compiler finds it it determines the size of the data
refered to and inserts it as a constant value. The sizeof operator won't
work at runtime. For it to work at runtime the compiler would have to
include a lot of extra code and information about a data type created to
help detemine sizes, and that wouldn't follow the standard AFAICT. To do
that would turn C/C++ into a higher level "safe" language that is also a
lot slower. So what does strcat() or strlen() do when you pass it a
dynamically allocated array that the compiler didn't know about at
compile-time? It won't use the sizeof. =20
=20

> unsigned char str[] =3D {'\200', '\250', '\210', '\300', '\0'};
>=20
> I've not looked up what those numbers do, but generally there=20
> are additional characters after 127 decimal (177 octal) that=20
> are special, i.e. graphics characters. I remind you that a=20
> backslash followed by a number is an octal number and not a decimal.

> A number having a \ is an escape sequence, *not* an octal number. 0200
> is an octal number (without ' ').
=20
I was refering to the fact that the number following the backslash is
interpreted as an octal constant and not as a decimal; it doesn't need
the preceding zero. Also if you write '\xff', that is a hexadecimal
character constant.
=20
Regards, Jason.

Im following a tutorial on opengl and when i try to compile the code I =
get errors. I think its becuase it cant find these header files:

#include <windows.h>
#include <gl\gl.h>
#include <gl\glu.h>
#include <gl\glaux.h>

Does dev-c++ have these files? Is there anything else i need to know =
before i start making opengl apps?

> As a hint take for example
> sizeof. sizeof even for ANSI standard knows the length of an array in
> the scope it was defined. How does it know? It's compiler stuff and
> compiler knows. So strcat() to search character after character would =
be
> stupid for a nowadays compiler. But it is *safe* to assume it looks
> character after character to find the '\0'.

It's important to realise that sizeof is a special compile time =
operator. When the compiler finds it it determines the size of the data =
refered to and inserts it as a constant value. The sizeof operator won't =
work at runtime. For it to work at runtime the compiler would have to =
include a lot of extra code and information about a data type created to =
help detemine sizes, and that wouldn't follow the standard AFAICT. To do =
that would turn C/C++ into a higher level "safe" language that is also a =
lot slower. So what does strcat() or strlen() do when you pass it a =
dynamically allocated array that the compiler didn't know about at =
compile-time? It won't use the sizeof.

=20
> unsigned char str[] =3D {'\200', '\250', '\210', '\300', '\0'};
>=20
> I've not looked up what those numbers do, but generally there=20
> are additional characters after 127 decimal (177 octal) that=20
> are special, i.e. graphics characters. I remind you that a=20
> backslash followed by a number is an octal number and not a decimal.

> A number having a \ is an escape sequence, *not* an octal number. 0200
> is an octal number (without ' ').

I was refering to the fact that the number following the backslash is =
interpreted as an octal constant and not as a decimal; it doesn't need =
the preceding zero. Also if you write '\xff', that is a hexadecimal =
character constant.

Regards, Jason.

> -----Original Message-----
> From: dev...@li...=20
> [mailto:dev...@li...] On Behalf=20
> Of Jason Hardman
> Sent: Wednesday, October 24, 2001 11:59 PM
> To: Dev-C++
> Subject: Re: [Dev-C++] Errorhandling
>=20
>=20
> While I don't want to kick up a fuss in this discussion I=20
> would like to point out firstly that search techniques in=20
> general rely on the structure to be searched being sorted=20
> into some specific order. It would be unreasonable to sort a=20
> string just so you can find the instance of a null, and it=20
> would invalidate the result anyway. ;) There isn't much more=20
> you can do in searching a string except by going in sequence=20
> through it. I know it has been mentioned that maybe a=20

You are talking about ANSI C way. But compiler stuff can be written in a
system dependend and more close to the machine way, so it can use win32
for example. It can use assembly, and generally the compiler knows
*more* than us from outside the compiler. As a hint take for example
sizeof. sizeof even for ANSI standard knows the length of an array in
the scope it was defined. How does it know? It's compiler stuff and
compiler knows. So strcat() to search character after character would be
stupid for a nowadays compiler. But it is *safe* to assume it looks
character after character to find the '\0'. As it is safe to assume it
is written in C doing that, but of course it can be written in whatever
language the compiler author wants (assembly, C++, ...). Usually C and
C++ are the case but it could be even fortran for some special cases
(precompiled the implementation file).


> compiler has optimisations to work around searching the=20
> entire length of a string to find it's end, but it's not=20
> something you can rely on. Adding these features would=20
> introduce a great deal of complexity into the compiler, but=20
> that is up to whoever writes it. I think you will find that=20
> the majority of compilers will actualy deal with string=20
> operations in the way you would expect from an external=20
> viewpoint. You will note that that standard C/C++ does not=20

Yes that's what i said.


> rely on knowing the lengths of arrays and will overrun their=20

ANSI C/C++ know the length of the arrays in the scope they were declared
using sizeof.

> ends if you are not careful. I would think that if the
> compiler had extra info about a string like it's length then=20
> it would use it in cases like this. In the end it's not=20

Yes it probably does.


> something I have to worry about.

I agree very much. :)


> Secondly, the use of the '\0' character is fairly limited,=20
> but there are some cases where it may be used. I agree that=20
> using it to manualy null terminate a string literal is bad=20
> practice and should be avoided.
>=20
> Possibilities for use of '\0' are:
>=20
> Manualy null terminating a string, i.e.
>=20
> char str[27];
> for(char i =3D 0; i < 26; ++i) str[i] =3D 'A' + i;
> str[26] =3D '\0';
> cout << str;
>=20
> Of course you could just as easily use a zero, but '\0' is in=20
> context to the operation this way.


Yes i agree but this is another case.


> or
>=20
> unsigned char str[] =3D {'\200', '\250', '\210', '\300', '\0'};
>=20
> I've not looked up what those numbers do, but generally there=20
> are additional characters after 127 decimal (177 octal) that=20
> are special, i.e. graphics characters. I remind you that a=20
> backslash followed by a number is an octal number and not a decimal.


A number having a \ is an escape sequence, *not* an octal number. 0200
is an octal number (without ' ').

=20
> Also I could envisage using it within a string literal as a=20
> way of breaking it up i.e. "Hello.\0This is a test.\0Break!",=20


Yes, but this is another case.


> of course I wouldn't recomend using a structure like this=20
> generally, but it's not impossible to envision a need for it.=20
> You would have to parse it manualy to obtain the strings or=20
> other data from it.
>=20
> Just some thoughts, Jason.


Ioannis

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

hello all,

I want to use wxWindows with DevC++. Can anybody tell
me how to make it work. How do I start?Is there
additional tools that I need?Will I be able to write
GUI application visually?

Thanks,

Edwin

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com