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

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hi all!

Does anyone know how do play mp3's in c++? I really could use some =
advice, cause I never had much luck with sounds in c++ :(

Thanks!

Stein Nyg=E5rd

Hi,
After some searching I found this on the GNU Libtool website.

http://www.gnu.org/software/libtool/manual.html#Inter-library%20dependen
cies

It seems I can't link in my GUI static library to my application because
it is dependent on the openGL and GLut libraries.
Dev-C++ does not allow linking of static libraries that depend on other
libraries.
I guess I can download the libtool, untar it, and use it in my makefile.
Seems like a pain though.
Does anyone know how to link in a library in Dev-C++ with inter-library
dependencies ?

Thanks,
Bobby

------------------------------------------------------------
Inter-library dependencies
By definition, every shared library system provides a way for
executables to depend on libraries, so that symbol resolution is
deferred until runtime. 

An inter-library dependency is one in which a library depends on other
libraries. For example, if the libtool library libhello uses the cos
function, then it has an inter-library dependency on libm, the math
library that implements cos. 

Some shared library systems provide this feature in an
internally-consistent way: these systems allow chains of dependencies of
potentially infinite length. 

However, most shared library systems are restricted in that they only
allow a single level of dependencies. In these systems, programs may
depend on shared libraries, but shared libraries may not depend on other
shared libraries. 

In any event, libtool provides a simple mechanism for you to declare
inter-library dependencies: for every library libname that your own
library depends on, simply add a corresponding -lname option to the link
line when you create your library. To make an example of our libhello
that depends on libm: 

burger$ libtool gcc -g -O -o libhello.la foo.lo hello.lo \
                -rpath /usr/local/lib -lm
burger$

When you link a program against libhello, you don't need to specify the
same -l options again: libtool will do that for you, in order to
guarantee that all the required libraries are found. This restriction is
only necessary to preserve compatibility with static library systems and
simple dynamic library systems. 

Some platforms, such as AIX, do not even allow you this flexibility. In
order to build a shared library, it must be entirely self-contained
(that is, have references only to symbols that are found in the .lo
files or the specified -l libraries), and you need to specify the
-no-undefined flag. By default, libtool builds only static libraries on
these kinds of platforms. 

The simple-minded inter-library dependency tracking code of libtool
releases prior to 1.2 was disabled because it was not clear when it was
possible to link one library with another, and complex failures would
occur. A more complex implementation of this concept was re-introduced
before release 1.3, but it has not been ported to all platforms that
libtool supports. The default, conservative behavior is to avoid linking
one library with another, introducing their inter-dependencies only when
a program is linked with them. 

confirm 196580

=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=
=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=
=B0=B0=B0=B0=B0=B0=B0
Maresca Paolo - assistant professor - researcher
Dis -  Universita' "Federico II" Napoli
Via Claudio, 21
80125 Napoli
Phone +39 081 7683168
Fax   +39 081 7683816
Email pao...@un...
http://maresca.ing.unina.it/

From: dev...@li...
[mailto:dev...@li...] On Behalf Of Bob
Wilson
Sent: Tuesday, April 09, 2002 4:05 PM
To: Dev-C++ User Mailing List
Subject: Re: [Dev-C++] Deliberate crashes - more information

Ioannis,

There are techniques which C++ inherently supports such as "resource
aquisition is initialization" that you can not apply if you do not know
how to define classes and work with objects. C++ is a very serious
thing, be patient and you will learn everything (i am still learning it
myself since summer 2000!). "Teach Yourself C++ in 24 Hours" (even 21
Days) could not cover the whole C++, imagine now the techniques that it
was designed to support. The book is excellent to make you reach close
to the intermediate level of C++ programming.

I am not impatient, but it makes absolutely no sense to not teach four
things when you teach a computer language. In order of importance they
are:

1.	

	The syntax or grammar of the language. It is impossible to do
any serious programming if you do not know the language. (I think this
is what you are saying, and I agree strongly with it.)
2.	

	Good language specific programming practices like initializing
all pointers as soon as they are created, deleting them as soon as you
are finished with them, and setting them to null or zero as soon as you
have deleted them. This is damn near as important as learning the
syntax. 

            Initializing all pointers and variables to some initial
value is something like a religious matter and has caused strong debates
among professional programmers in various discussion groups i
participate.

There is the opinion that initializing them to some value can help
discover bugs easier since the start value doesn't produce random
behavior which helps debugging and the opinion that if you initialise
with a certain value may hide some bug which will be discovered too
late, which would have been discovered in the testing process if it had
no start value.

My approach on this matter is that one of the benefits of C++ is that it
allows to you define variables in the first place you need them, so
don't define everything at the beginning (which by itself increases the
possibility of a bug) but define everything in the first place you need
it.

1.	

1.	

2.	

3.	

	Elucidation of how to solve or avoid common language related
programming problems. 
4.	

	How to make your language specific code bullet proof.  

I think the bullet-proof code is a thing that must be taught after the
basics.
Ioannis

* Ioannis Vranos
* Programming pages:  <http://www.noicys.cjb.net/>
http://www.noicys.cjb.net
* Alternative URL:  <http://run.to/noicys> http://run.to/noicys

To All Bloodshed Experts:=20
(This is not a C++ question)

I wasted three hours late last night trying to compile and run three =
programs, each of which compiled and ran perfectly after some small =
corrections to some typing errors. The programs were copied from Sams =
Teach Yourself C++ in 24 hours, Third Edition by Jesse Liberty.=20

So, if they compiled and ran properly, what was the problem?=20

In the interest of ease of identification later (i.e., self =
documentation of a program's purpose), I gave discriptive names to both =
the project files and the actual programs.=20

                          Project File Name                              =
                             Associated Source File Name
  Passing Function Arguments by Pointer.dev    =
Passing_Function_Arguments_by_Pointer.cpp*
  Passing Function Arguments by Reference.dev  =
Passing_Function_Arguments_by_Reference.cpp*
  Passing Function Arguments by Value.dev      =
Passing_Function_Arguments_by_Value.cpp*

*The underline charcters were used between words rather than spaces =
because the Bloodshed environment does not allow a C++ program to have =
the same name as=20

However, I was unable to produce more than two .exe files in the same =
directory, and if I built or compiled the same file twice, the other =
.exe file would disappear.

When I shortened the names to:

          Project File Name                                           =
Associated Source File Name
  Passing by Pointer.dev        =
Passing_Function_Arguments_by_Pointer.cpp
  Passing by Reference.dev      =
Passing_Function_Arguments_by_Reference.cpp
  Passing by Value.dev          Passing_Function_Arguments_by_Value.cpp

all three compiled and there were three .exe files in the directory.=20

        Executable File Name
  Passing by Pointer.exe
  Passing by Reference.exe
  Passing by Value.exe

Earlier, Ioannis Varnos and I had exchanged emails about a problem I =
experienced with the Bloodshed programming environment, and she had =
recommended that I stay away from the project creation function of the =
Bloodshed environment and stick to creating and compiling non project =
related C++ programs. I discovered that the solution to my problem lay =
in making direct changes to the undocumented .dev or project file with =
the notepad, so I continued to work with projects. Eureka! I thought and =
searched the .dev files for a truncation of my long file names, but they =
were not truncated in the project files.=20

With Ioannis' advice in mind, I closed the project file upon which I was =
working and brought the .cpp files listed above into the Bloodshed =
"shell" one at a time and compiled them. The results were the same. I =
was unable to produce more than two .exe files in the same directory, =
and if I built or compiled the same file twice, the other .exe file =
would disappear.=20

Although it is not documented, at least I cannot find it, there must be =
a maximum length of a file name beyond which the compiler/linker =
combination throws away or disregards the rest of the file name. When =
the compiler/linker erased a previously existing .exe file of a =
different name, it always erased the oldest. That leads me to believe =
that it searches from the top until it finds a file that matches the =
compiler's target file name, at least to the limits of its file name =
space, it deletes, and writes a new one, or it overwrites it and changes =
the name in the file directory. My guess is that the some part of the =
compiler or linker does not support the full length of windows file =
names. If this is the case, it is a flaw that should be fixed. =
Ironically, the names of any .exe file compiled and linked was never =
truncated.=20

Before someone goes on the "yer-files-names-are-too-damn-long" rampage, =
consider the fact that, unless a compiler is totally compatible with =
operating system conventions, it is not operating system compliant, and, =
as such, it is not as versatile or as useful as it could be. Any such =
limitations or variances should be well documented and internal error =
trapping routines should provide immediate warnings to the user if =
he/she exceeds a limit such as the allowed length of the file name =
allowed by the programming environment which will result in the type of =
problems documented above.=20

I truly hope that someone will send me an email that points out how I =
either missed the obvious, i.e., the documentation, help screen, option, =
etc., but I don't hold out much hope of that. I would be interested in =
knowing any other things like this that others have discovered.=20

Regards,

Bob Wilson

you can use memset also including <string.h>
remember that the first argument of memset is a
pointer.
this is the memset way to initialize a structure

{
struct yourStruct newStruct;
memset(&newStruct, 0, sizeof(struct yourStruct)); 
}
ciao

______________________________________________________________________
Iscriviti al Club Nokia, è gratis!
http://it.yahoo.com/mail_it/foot/?http://www.club.nokia.it/

MessageIoannis,
  There are techniques which C++ inherently supports such as "resource =
aquisition is initialization" that you can not apply if you do not know =
how to define classes and work with objects. C++ is a very serious =
thing, be patient and you will learn everything (i am still learning it =
myself since summer 2000!). "Teach Yourself C++ in 24 Hours" (even 21 =
Days) could not cover the whole C++, imagine now the techniques that it =
was designed to support. The book is excellent to make you reach close =
to the intermediate level of C++ programming.
I am not impatient, but it makes absolutely no sense to not teach four =
things when you teach a computer language. In order of importance they =
are:

    1.. The syntax or grammar of the language. It is impossible to do =
any serious programming if you do not know the language. (I think this =
is what you are saying, and I agree strongly with it.)
    2.. Good language specific programming practices like initializing =
all pointers as soon as they are created, deleting them as soon as you =
are finished with them, and setting them to null or zero as soon as you =
have deleted them. This is damn near as important as learning the =
syntax.
    3.. Elucidation of how to solve or avoid common language related =
programming problems.
    4.. How to make your language specific code bullet proof.=20
Number two, three, and four above should be focused on whatever language =
feature or syntactical device is under discussion. If avoiding language =
specific programming errors is different from one operating system to =
another, or there is a language specific problem in one operating system =
and not the others, that should be mentioned along with a link or =
reference to where to find more detailed information should the =
reader/student so desire.=20

Number three and four above should be strictly language specific and =
should be supported with one or more examples. (By specifically language =
specific I mean without regard to MFC, the win32 API or any operating =
system.) Such efforts should not be forced or artificial.=20

I did not list it because it should be obvious, but enough instruction =
must be given about the programming environment to avoid environment =
related interruptions in or distractions to the learning process. Some =
teachers, books, etc., are better than others in that regard.=20

Regards,

Bob

Hi,
I tried this and it didn't seem to make a difference.  It's weird
because the linker is finding the library
it just doesn't know how to process the opengl commands found in my
library.  Even though I am including
the opengl libraries in my main program!

I've found some information on libtool on the web, but it didn't come
with the mingW32 compiler stuff.
Anyone have an idea where I can go to get a copy that will run with my
version of Dev-C++ (4.01)?
Thanks again,
Bobby

-----Original Message-----
From: dev...@li...
[mailto:dev...@li...] On Behalf Of Evan
Hempel <ech...@ne...>
Sent: Monday, April 08, 2002 5:09 PM
To: "Dev-C++"
Cc: "Robert Landle"
Subject: RE: [Dev-C++] Problem linking in library

>   Hello,
>   I am very new to Dev-C++ so excuse my ignorance.  I've been blindly
>   using the big money C++ compiler, but now I'm better. 
>   Here is my deal.
>
>   I have a gui development library that utilizes opengl and glut that
I
>   want to link into my appication.
>   Here are the steps I took.
>
>   1.  Compiled the library
>   2.  Developed an archive file from the object files using the
command
>   line gcc archive command (ar -ru lib.a *.o).
>   3.  Created a new project that links in -lopengl32 -lglu32 -lglut32
and
>   lib.a.  (I put this in Further object files section of the project
>   options window).

I believe that libraries for gcc are suposed to be named lib<name>.a ie
libgl.a, libc.a, ...  and then are linked by -l<name> -lgl -lc ...  So
you might want to try naming the file libsomething.a  Changing this
might be resolve the error.

Evan

>   4.  Attempted to compile my application
>
>   When Dev-C++ attempts to link in the library it gives me an
"undefined
>   reference to `opengl function' error.
>   It's almost as if it doesn't know where to find the opengl functions
>   that I included.
>
>   If I put the whole library source code into my project I can
compile,
>   link, and run the project without a hitch.
>
>   Any clues as to what I'm doing wrong?
>
>   Thanks for you help.
>   Bobby

__________________________________________________________________
Your favorite stores, helpful shopping tools and great gift ideas.
Experience the convenience of buying online with Shop@Netscape!
http://shopnow.netscape.com/

Get your own FREE, personal Netscape Mail account today at
http://webmail.netscape.com/

_______________________________________________
Dev-cpp-users mailing list
Dev...@li...
https://lists.sourceforge.net/lists/listinfo/dev-cpp-users

Sponsored by http://www.ThinkGeek.com/

Thanks Stein and Ioannis, very helpful!

>From: Stein Nygård <ste...@ge...>
>To: "Daniel Glenfield" <sp...@ho...>
>Subject: Re: [Dev-C++] memset
>Date: Tue, 9 Apr 2002 14:57:18 +0200
>
>Sets n bytes of s to c
>memset(void *s, int c, size_t n);
>
>Example:
>
>#include <mem.h>
>int main(void)
>{
>     char buffer[8];
>     memset(buffer, 'k', 8);
>     return 0;
>}
>
>Hope, that helped :)
>
>- Stein Nygård
>
>
>----- Original Message -----
>From: "Daniel Glenfield" <sp...@ho...>
>To: <dev...@li...>
>Sent: Tuesday, April 09, 2002 1:26 PM
>Subject: [Dev-C++] memset
>
>
> > Hi all,
> > what is memset all about? memory set? anybody know? I'm doing work with
>MFC.
> >
> > _________________________________________________________________
> > MSN Photos is the easiest way to share and print your photos:
> > http://photos.msn.com/support/worldwide.aspx
> >
> >
> > _______________________________________________
> > Dev-cpp-users mailing list
> > Dev...@li...
> > https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

I have gaps in my knowledge lol.
What's a MAKE file, and what does it do?

_________________________________________________________________
Join the worlds largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

memset() is an ANSI C/C++ function that sets an amount of bytes in
memory to some value.

Ioannis

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

> -----Original Message-----
> From: dev...@li... 
> [mailto:dev...@li...] On Behalf 
> Of Daniel Glenfield
> Sent: Tuesday, April 09, 2002 1:26 PM
> To: dev...@li...
> Subject: [Dev-C++] memset
> 
> 
> Hi all,
> what is memset all about? memory set? anybody know? I'm doing 
> work with MFC.
> 
> _________________________________________________________________
> MSN Photos is the easiest way to share and print your photos:
> http://photos.msn.com/support/worldwide.aspx
> 
> 
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
> 

> -----Original Message-----
> From: dev...@li... 
> [mailto:dev...@li...] On Behalf 
> Of David McKen
> Sent: Tuesday, April 09, 2002 6:43 AM
> To: dev...@li...
> Subject: [Dev-C++] What is the scope of preprocessor directives???
> 
> 
> What is the scope of a preprocessor directive?

The scope of the rest of its file and the files in which its file is
included. Or till one other directive that cancels it.

> 
> For example if I put a #define what statements are affected by it?
> 
> Also if I have a *.h file that has a set of #defines in it will they
> affect other files in the project or am I restricted to the command
> line for that

Yes they can if you #include the file in other files. But you must try
hardly to not happen that. So use large & ugly names for macros and if
possible #undef them at the end of their use.

Ioannis

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

-----Original Message-----
From: dev...@li...
[mailto:dev...@li...] On Behalf Of Bob
Wilson
Sent: Tuesday, April 09, 2002 3:22 AM
To: Dev-C++ User Mailing List
Subject: Re: [Dev-C++] Deliberate crashes - more information

And now we get back into an area of a potential disagreement. In
addition to teaching the syntax of a language, any teacher, tutorial,
book, etc., should make sure all of its examples are bullet proof, and,
where appropriate, methods of insuring that any code created with the
language feature under discussion should be discussed. Good langruage
specific programming practices should not be separated from the
fundementals of good code design.  

There are techniques which C++ inherently supports such as "resource
aquisition is initialization" that you can not apply if you do not know
how to define classes and work with objects. C++ is a very serious
thing, be patient and you will learn everything (i am still learning it
myself since summer 2000!). "Teach Yourself C++ in 24 Hours" (even 21
Days) could not cover the whole C++, imagine now the techniques that it
was designed to support. The book is excellent to make you reach close
to the intermediate level of C++ programming.

Ioannis

* Ioannis Vranos
* Programming pages: http://www.noicys.cjb.net
<http://www.noicys.cjb.net/> 
* Alternative URL: http://run.to/noicys

Hi all,
what is memset all about? memory set? anybody know? I'm doing work with MFC.

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

What is the scope of a preprocessor directive?

For example if I put a #define what statements are affected by it?

Also if I have a *.h file that has a set of #defines in it will they 
affect other files in the project or am I restricted to the command
line for that

__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/

MessageIoannis,
  It's all theoretical, you may try to place data in address you assume =
allocated too. From my experience making it 0 doesn't protect you in =
reality if you do not know what is going on. :) The last thing you will =
do on a pointer assuming it points to allocated space is to delete it. =
Before you will try to read/write from there (and boom even if it is 0). =
So the real solution to such problems is to know what is going on in the =
code.=20
Boy! Do I agree those two statements. Perhpas the most practical =
demonstration of the importance of knowing what is going on in the code =
is when you import a source code routine that someone else has written, =
and there are problems with the either logic or the syntax. If you do =
not understand the underlying algorithm and the coding, it is impossible =
to fix the problem. It goes without saying that code that is written in =
a clear, self-documenting style filled with enough comment to make the =
code crystal clear.=20
  For knowing what is going on, keep code separated inside small =
functions each of one doing some specific job.=20
Again I could not agree more. Weveral years ago when the amount of =
memory available for code space was limited either by the cost of ram or =
software and hardware architectures, building many small functions was =
not feasible because the overhead associated with such a metohdology =
quickly filled and often overran the space available.=20
  There are ways for bullet-proof code but it is not yet the time for =
you to think of them, just keep learning and keep experimenting with C++ =
as you are doing.
And now we get back into an area of a potential disagreement. In =
addition to teaching the syntax of a language, any teacher, tutorial, =
book, etc., should make sure all of its examples are bullet proof, and, =
where appropriate, methods of insuring that any code created with the =
language feature under discussion should be discussed. Good langruage =
specific programming practices should not be separated from the =
fundementals of good code design.=20

It's all theoretical, you may try to place data in address you assume
allocated too. From my experience making it 0 doesn't protect you in
reality if you do not know what is going on. :) The last thing you will
do on a pointer assuming it points to allocated space is to delete it.
Before you will try to read/write from there (and boom even if it is 0).
So the real solution to such problems is to know what is going on in the
code. For knowing what is going on, keep code separated inside small
functions each of one doing some specific job. There are ways for
bullet-proof code but it is not yet the time for you to think of them,
just keep learning and keep experimenting with C++ as you are doing.

Ioannis

* Ioannis Vranos
* Programming pages: http://www.noicys.cjb.net
<http://www.noicys.cjb.net/> 
* Alternative URL: http://run.to/noicys

-----Original Message-----
From: dev...@li...
[mailto:dev...@li...] On Behalf Of Bob
Wilson
Sent: Tuesday, April 09, 2002 1:52 AM
To: Dev-C++ User Mailing List
Subject: Fw: [Dev-C++] Deliberate crashes - more information

>> Why call delete an an already deleted pointer in the first place and
why to assign it to zero and call delete on it? :) <<

Intentionally? There is no reason. Unintentionally, there is no reason
either, but the possibility of an accidental second delete on a non null
pointer increases with the size and complexity of the program and the
number of programmers involved with the project. 

>> Why call delete an an already deleted pointer in the first place and =
why to assign it to zero and call delete on it? :) <<

Intentionally? There is no reason. Unintentionally, there is no reason =
either, but the possibility of an accidental second delete on a non null =
pointer increases with the size and complexity of the program and the =
number of programmers involved with the project.=20

> -----Original Message-----
> From: dev...@li... 
> [mailto:dev...@li...] On Behalf 
> Of Brian Pribis
> Sent: Tuesday, April 09, 2002 12:46 AM
> To: Dev-C++ User Mailing List
> Subject: Re: [Dev-C++] Deliberate crashes - more information
> 
> 
> There are many more, but they are worse then these and there may be
> children reading this list.  So, don't call delete on an 
> already deleted
> pointer unless you first assign it null. Period!

Why call delete an an already deleted pointer in the first place and why
to assign it to zero and call delete on it? :)

Ioannis

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

Yes and to clarify the issue more here what is written in "The C++
Programming Language" 3rd Edition or Special Edition by Bjarne
Stroustrup (the creator of C++) (this is the Bible of C++):

On page 128:

"The delete operator may be applied only to a pointer returned by new or
to zero. Applying delete to zero has no effect".

And for delete[] some lines down: "Applying delete[] to zero has no
effect".

But in general you should know whether the pointer points to allocated
memory or not. And for bullet-proof code try using the C++ containers
instead.

Ioannis

* Ioannis Vranos
* Programming pages: http://www.noicys.cjb.net
<http://www.noicys.cjb.net/> 
* Alternative URL: http://run.to/noicys

-----Original Message-----
From: dev...@li...
[mailto:dev...@li...] On Behalf Of Bob
Wilson
Sent: Monday, April 08, 2002 11:46 PM
To: Dev-C++ User Mailing List
Subject: [Dev-C++] Deliberate crashes - more information

Ladies and gentlemen:

Earlier I posted an lengthy "treatise" on problems related to quote from
Sams Teach Yourself C++ in 24 Hours, third Edition by Jesse Liberty.
Since that posting I have exchanged several lengthy emails with the
author concerning what I perceived as a problem with the wording of his
warning. During the corse of the day, I believe we have come to an
understanding. Mr. Liberty has asked that I inform the readers of the
Dev-C++ User Mailing List of the results of this discussion. He was
concerned that my comments would make people think that he had "got this
wrong." To that end, I am forwarding the entire thread of our
correspondance in reverse cronological order. 

Dear all:
For those newbies out there, the moral of this story is NEVER,ever, EVER
delete a pointer without afterwards assigning it NULL (0).  I have
received numerous emails from beginners and experts alike who have not
done this and have experienced some of the following horrific events:
(The names have been withheld to protect the guilty)

A New York man claimed that his under-ware spontaneously sprung up over
his head nearly suffocating him.
A woman claimed her cat (fluffy) gave a load meow and died on the spot.
A 17 year-old from Vancouver,BC said a meteor crashed through his house
and destroyed his computer and lobotomized his dog.
A man, hard of hearing, claimed that he gained his hearing back...only
to lose his sight.
A CA professor found himself stranded on a desert Isle with six other
(slightly neurotic) passengers.
Finally (and this is the worse by far) a gentleman was forced to port an
entire beginners C++ book to Ada simply for pointing out grammatical
inconsistencies dealing with pointers in C++ books.

There are many more, but they are worse then these and there may be
children reading this list.  So, don't call delete on an already deleted
pointer unless you first assign it null. Period!

b--

On Mon, 2002-04-08 at 14:45, Bob Wilson wrote:

(Please see the rest of this thread for the gory details).

Ladies and gentlemen:

Earlier I posted an lengthy "treatise" on problems related to quote from =
Sams Teach Yourself C++ in 24 Hours, third Edition by Jesse Liberty. =
Since that posting I have exchanged several lengthy emails with the =
author concerning what I perceived as a problem with the wording of his =
warning. During the corse of the day, I believe we have come to an =
understanding. Mr. Liberty has asked that I inform the readers of the =
Dev-C++ User Mailing List of the results of this discussion. He was =
concerned that my comments would make people think that he had "got this =
wrong." To that end, I am forwarding the entire thread of our =
correspondance in reverse cronological order.=20

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

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

No problem.

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

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

Okay, I'll work on it. Thanks for the feedback!

-j

-------------------------------
Jesse Liberty
Liberty Associates, Inc.
.NET Training & Development
http://www.LibertyAssociates.com=20

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

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

Jesse,
  I don't think this substantially changes the meaning of the chapter, =
but you are of course free to disagree.
Neither do I, but I would suggest that:
  Calling delete on that pointer again may crash your program!
is neither as strong a warning nor as precise as what I suggested. By =
simply inserting "may," you might be weakening the warning to the point =
that the uninitiated (or, if you prefer, the great unwashed masses =
uncleansed by the purity of C++) would not consider it grevious error to =
not set used pointers to null.=20

Regards,

Bob

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

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

Bob,

Yes, of course, the book should have made the sentence more precise, and =
I'll fix that. The example you quoted in your original post, however, =
was not on point: it showed the reuse of a deleted pointer, and that of =
course will crash. I thought at the time you were complaining that =
marking the pointer to null did not protect you from that crash (which I =
never said it would). It turns out, apparently that you were actually =
complaining that the non-nulled deleted pointer did not crash as I said =
it would

>> How could someone who is expert enough to write a beginning book on =
C++ make such an error=20

Seems like a bit of overstatement to me, but I will in the next edition =
qualify the sentence to=20
 Calling delete on that pointer again may crash your program!

I don't think this substantially changes the meaning of the chapter, but =
you are of course free to disagree.

Thanks.

-j

-------------------------------
Jesse Liberty
Liberty Associates, Inc.
.NET Training & Development
http://www.LibertyAssociates.com=20

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

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

Jesse,
  Yes. It will crash the program. Sooner or later. If you call delete on =
a pointer and you do not set it to null, it is pointing to random =
memory. That may work for a while, but it certainly will crash sooner or =
later. The only safe alternative is declare it null. =20
A simple declarative sentence that purports to state a universal fact =
without any clauses that restrict or modify the universality of that =
fact must be assumed to apply to all situations. In making a simple =
declarative statement without any sort of limiting modifiers, you state =
that all programs will crash. They do not. Your quote appears on page =
147. Directly below the quote is an example program which will not crash =
if you delete a deleted pointer. In the simplest employment of =
Aristotelian logic, if you show that something contradicts itself, you =
have shown that the thing is untrue. I have done that, therefore your =
statement is incorrect, invalid, or not true. Like it or not, you made =
an error when you wrote the warning. Using an exclamation point to end =
the sentence under discussion only strengthens my criticism.=20

That said, I concur that a dangling pointer is like a smoldering ember =
in a room full of gasoline and gunpowder. Further I agree that only a =
fool or a very inexperienced or careless programmer fails to both return =
memory to the heap and set pointers to null after they have been used.=20
  You have a few things confused here:

  1. Delete a pointer and do not null it. Then call delete again. It CAN =
crash immediately, and will crash sooner or later.
I go back to what I said before. Your quote from the book is a absolute. =
It is not a conditional statement as "It CAN crash immediately" above =
is. Simply put, the book should have had been more accurate. Your entire =
sentence above, "It CAN crash immediately, and will crash sooner or =
later", suffers from the same problem. You and I can both write a simple =
program that deletes a deleted pointer and the program will not crash =
but run through to its normal termination. Such a contradiction makes =
the sentence above and in the book inaccurate. The boxed warning on page =
147, should have read:=20
  When you call delete on a pointer, the memory it points to is freed. =
Calling delete on that pointer again may not cause a program to crash =
immediately, and a simple program like the one in listing 9.4 below may =
not crash at all, but more complex, longer running programs will =
ultimately crash.=20
If your warning had been worded in that fashion, it would have been 100% =
accurate, and we would not be having this discussion.
  2. Delete a pointer and use it again (e.g., assign a value to it). =
That will crash, sooner or later
Agreed , but the criticism and comments discussed above apply to this =
absolute statement as well.=20
  3. Delete a pointer and assign null. Then delete again. That is safe, =
as I said in the book
Agreed.=20
  4. Delete a pointer and assign null and then reuse it. Should crash =
right away
Agreed.=20
  Your example in your email was of #4, and it crashes just as it said. =
The book was not wrong. I'm sorry I wasn't clearer, but the book was =
correct.
This may be a very nit-picky argument that deals with both the syntax =
and grammar of English, but your warning in the book is wrong. Examine =
the original statement on page 147, what you have posted to me, and what =
I have posted above. Hopefully such an examination will show you why I =
am so adamant. If you cannot see the difference, and why I maintain that =
the warning in the book is wrong, I will try to give you a better =
explanation of why that is so.=20

  Please post a correction to the dev-c mailing list you originally =
posted the criticism on.
I will be happy to oblige once the issue is settled.=20

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

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

Bob,
I am sorry as well. What you said, and I quote, "When you call delete on =
a pointer, the memory it points to is freed. Calling delete on that =
pointer again will crash your program!" In point of fact it does not =
crash the program. Try it with either the Bloodshed or the VC++ 6.0 =
compiler and you will see what I mean. =20

Yes. It will crash the program. Sooner or later. If you call delete on a =
pointer and you do not set it to null, it is pointing to random memory. =
That may work for a while, but it certainly will crash sooner or later. =
The only safe alternative is declare it null. =20

You have a few things confused here:

1. Delete a pointer and do not null it. Then call delete again. It CAN =
crash immediately, and will crash sooner or later.
2. Delete a pointer and use it again (e.g., assign a value to it). That =
will crash, sooner or later
3. Delete a pointer and assign null. Then delete again. That is safe, as =
I said in the book
4. Delete a pointer and assign null and then reuse it. Should crash =
right away

Your example in your email was of #4, and it crashes just as it said. =
The book was not wrong. I'm sorry I wasn't clearer, but the book was =
correct.

    PS: Please do update the mailing list (I don't have the email =
address) on which you posted this msg; I'd hate for folks to think I got =
this wrong.
  Please excuse my ignorance, but update what mailing list? Or perhaps =
you mean to post a correction. =20

  Please post a correction to the dev-c mailing list you originally =
posted the criticism on.

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

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

  I'm sorry but the book is correct. Please examine what I wrote and =
compare it to what you did in your test program.

  I said you can set a pointer to null and then delete it without it =
crashing. That is 100% correct.
     Calling delete on a null pointer is guaranteed to be safe.
I am sorry as well. What you said, and I quote, "When you call delete on =
a pointer, the memory it points to is freed. Calling delete on that =
pointer again will crash your program!" In point of fact it does not =
crash the program. Try it with either the Bloodshed or the VC++ 6.0 =
compiler and you will see what I mean.=20
  I did not say you can then try to use the pointer, or assign a new =
value to it. You can not, and I make that explicitly clear in the book.=20

  You write:
  If set pHeap to null, however, and then try to assign *pHeap a value, =
as shown below, the program will crash.=20

  Right. It will crash, as it should; once set to null you can not then =
assign a value to it. All you can safely do is call delete.=20
I agree wholeheartedly, it should crash and it does. However, that was =
not my initial criticism. It was an outgrowth of experimentation to see =
if the program would crash as similar programs in other languages do if =
you try to manipulate a null pointer.=20
  As part of my ongoing effort to support my books, I now offer a FAQ, =
source code and related materials on my web site: =
http://www.LibertyAssociates.com. While you are there, you may want to =
sign up for my on-line support discussion center: =
http://forums.delphiforums.com/LibertyBooks. I'm happy to discuss this =
in detail on the discussion center if there is still any confusion.

I will certainly log on to your forms. Thanks for the link.=20

  PS: Please do update the mailing list (I don't have the email address) =
on which you posted this msg; I'd hate for folks to think I got this =
wrong.
Please excuse my ignorance, but update what mailing list? Or perhaps you =
mean to post a correction.=20

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

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

I'm sorry but the book is correct. Please examine what I wrote and =
compare it to what you did in your test program.

I said you can set a pointer to null and then delete it without it =
crashing. That is 100% correct.
   Calling delete on a null pointer is guaranteed to be safe.

I did not say you can then try to use the pointer, or assign a new value =
to it. You can not, and I make that explicitly clear in the book.=20

You write:
If set pHeap to null, however, and then try to assign *pHeap a value, as =
shown below, the program will crash.=20

Right. It will crash, as it should; once set to null you can not then =
assign a value to it. All you can safely do is call delete.=20

In fact elsewhere in the book I point out that this is a feature, it =
crashes reliably, as opposed to what happens if you delete memory and do =
not assign it to null (in which case, if you use the pointer you =
overwrite random memory and it crashes unpredictably).

As part of my ongoing effort to support my books, I now offer a FAQ, =
source code and related materials on my web site: =
http://www.LibertyAssociates.com. While you are there, you may want to =
sign up for my on-line support discussion center: =
http://forums.delphiforums.com/LibertyBooks. I'm happy to discuss this =
in detail on the discussion center if there is still any confusion.

Thank you.=20

-j

PS: Please do update the mailing list (I don't have the email address) =
on which you posted this msg; I'd hate for folks to think I got this =
wrong.
-------------------------------
Jesse Liberty
Liberty Associates, Inc.
.NET Training & Development
http://www.LibertyAssociates.com=20

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

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

(I forwarded my original message to Mr. Liberty at =
jli...@li...)

I will appologize in advance for the length of this message. Anyone who =
has much experience in programming knows pointers are an extremely =
powerful and useful construct, but that they can be the quickest path to =
the hellfire and damnation of runtime erros and program crashes if =
careful attention is not paid to how they are used.=20

With that as a backdrop here is a quote from Sams Teach Yourself C++ in =
24 Hours, third Edition by Jesse Liberty.=20

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

When you call a delete on a pointer, the memory it points to is freed. =
Calling delete on that pointer again will crash your program! When you =
delete a pointer, set it to 0 (null). Calling delete on a null pointer =
is guaranteed to be safe. For example

  Animal: *pDog =3D new Animal;
  delete pDog; // frees the memory
  pDog =3D 0; // sets the pointer to null
  // . . .
  delete pDog; // harmless

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

But it does not work that way. As a matter of fact with both the =
Bloodshed/GNU compiler supplied with the book and VC++ 6.0 it works just =
the opposite. The book uses this program to demonstrate allocating and =
deleting a pointer.=20

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

 // Listing 9.4
 // Allocating and deleting a pointer

 #include <iostream>

 int main()
 {
     int localVariable =3D 5;
     int * pLocal=3D &localVariable;
     int * pHeap =3D new int;
     if (pHeap =3D=3D NULL)
     {
         std::cout << "Error! No memory for pHeap!!";
         return 1;
     }
     *pHeap =3D 7;
     std::cout << "localVariable: " << localVariable << "\n";
     std::cout << "*pLocal: " << *pLocal << "\n";
     std::cout << "*pHeap: " << *pHeap << "\n";
     delete pHeap;
     pHeap =3D new int;
     if (pHeap =3D=3D NULL)
     {
         std::cout << "Error! No memory for pHeap!!";
         return 1;
     }
     *pHeap =3D 9;
     std::cout << "*pHeap: " << *pHeap << "\n";
     delete pHeap;
     return 0;
 }

=20

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

If you compile and run the program the output is as advertised in the =
book;

  localVariable: 5
  *pLocal: 5
  *pHeap: 7
  *pHeap: 9
However if you modify the code by setting pHeap to null and call delete =
on pHeap immedately after as shown below. The program still runs without =
error.=20

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

 // Listing 9.4
 // Allocating and deleting a pointer

 #include <iostream>

 int main()
 {
     int localVariable =3D 5;
     int * pLocal=3D &localVariable;
     int * pHeap =3D new int;
     if (pHeap =3D=3D NULL)
     {
         std::cout << "Error! No memory for pHeap!!";
         return 1;
     }
     *pHeap =3D 7;
     std::cout << "localVariable: " << localVariable << "\n";
     std::cout << "*pLocal: " << *pLocal << "\n";
     std::cout << "*pHeap: " << *pHeap << "\n";
     delete pHeap;
     delete pHeap;                    // Try to crash program
     pHeap =3D new int;
     if (pHeap =3D=3D NULL)
     {
         std::cout << "Error! No memory for pHeap!!";
         return 1;
     }
     *pHeap =3D 9;
     std::cout << "*pHeap: " << *pHeap << "\n";
     delete pHeap;
     return 0;
 }

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

If set pHeap to null, however, and then try to assign *pHeap a value, as =
shown below, the program will crash.=20

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

 // Listing 9.4
 // Allocating and deleting a pointer

 #include <iostream>

 int main()
 {
     int localVariable =3D 5;
     int * pLocal=3D &localVariable;
     int * pHeap =3D new int;
     if (pHeap =3D=3D NULL)
     {
         std::cout << "Error! No memory for pHeap!!";
         return 1;
     }
     *pHeap =3D 7;
     std::cout << "localVariable: " << localVariable << "\n";
     std::cout << "*pLocal: " << *pLocal << "\n";
     std::cout << "*pHeap: " << *pHeap << "\n";
     pHeap =3D 0;
     *pHeap =3D33;
     pHeap =3D new int;
     if (pHeap =3D=3D NULL)
     {
         std::cout << "Error! No memory for pHeap!!";
         return 1;
     }
     *pHeap =3D 9;
     std::cout << "*pHeap: " << *pHeap << "\n";
     delete pHeap;
     return 0;
 }

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

I have several questions.

    1.. How could someone who is expert enough to write a beginning book =
on C++ make such an error=20
    2.. Is it perhaps because the ANSI/ISO definition of the language =
and what a compiler should do has changed?=20
    3.. Have GNU and the Gates crowd made similar unilateral changes to =
solve a pesky problem?=20
    4.. Did I misread something which seems fairly straight forward?=20
    5.. Are there other pointer inconsistances hiding in the weeds =
waiting to pounce on the unsuspecting?

>   Hello,
>   I am very new to Dev-C++ so excuse my ignorance.  I've been blindly
>   using the big money C++ compiler, but now I'm better. 
>   Here is my deal.
>
>   I have a gui development library that utilizes opengl and glut that I
>   want to link into my appication.
>   Here are the steps I took.
>
>   1.  Compiled the library
>   2.  Developed an archive file from the object files using the command
>   line gcc archive command (ar -ru lib.a *.o).
>   3.  Created a new project that links in -lopengl32 -lglu32 -lglut32 and
>   lib.a.  (I put this in Further object files section of the project
>   options window).

I believe that libraries for gcc are suposed to be named lib<name>.a ie libgl.a, libc.a, ...  and then are linked by -l<name> -lgl -lc ...  So you might want to try naming the file libsomething.a  Changing this might be resolve the error.

Evan

>   4.  Attempted to compile my application
>
>   When Dev-C++ attempts to link in the library it gives me an "undefined
>   reference to `opengl function' error.
>   It's almost as if it doesn't know where to find the opengl functions
>   that I included.
>
>   If I put the whole library source code into my project I can compile,
>   link, and run the project without a hitch.
>
>   Any clues as to what I'm doing wrong?
>
>   Thanks for you help.
>   Bobby

__________________________________________________________________
Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/

I don't know any utility for do so, except for the reimp, but i didn't find
where to download it from (ehm, sorry my english), it is the only I found about
the matter.

Well, I revised the bin directory of Dev-cpp and i found that none of the
executables (cpp.exe, g++.exe, etc) can be ran as console and typed in the
commands. And there is mv.exe.
I have proved to run cmd.exe (I use windows 2000, for windows 9x run
command.exe) and typed the instruction
mv library.lib library.a
, and it worked. So it shall work for you. If not, check if the Dev Bin
directory is added in your system path.(1)[this is a call to the bottom of the
page]***I know you know that, but I have the experience always I use footnotes
the reader miss the call***
[Red means you can not read it] (Or is it asking for the mv order of cygwin?. I
don't think so. In the Dev directory is a file called mv.c and there a function
which does it, so although it was the cygwin function which is called in my
computer, in the yours it shall call the mv.exe of mingw32 of Dev and work fine)

I searched mv in the help of Dev-C++ but there are not any help about it.

I also tried to use it in the further compiler options either in the project
options dialog and in the compiler options dialog, but neither worked, it says
then that mv and the destination file don't exist.

Chris Moore escribió:

> Thanks for the info. However, it's still not clear to me how to convert my
> ".lib" file to a "lib*.a" file. I saw the reference to the "reimp" tool, but
> I was having troble using this tool.
>
> Are there any other tools that you know of that will convert the .lib to a
> lib*.a?
>
> Thanks!
>
> Chris

(1) In windows 2000 set path with control panel -> system -> advanced ->
environment variables. Select path, edit it and add the directory. I don't know
well if in win9x it is done the same, but it seems you must use command.exe and
do I don't know what. (If you don't know I can send you a very small file where
it is said how to do it.)

Oh! I didn't noticed it, in mv.c what the function does is simply copy
from one archive to other, so it is simply like rename. And it work, at
least with winbgi.lib.

Where did you find reimp?

Type in the command.exe the next command:
      path c:\mingw32\bin;%PATH%
and so you set the path, and this is valid for windows 9x, or type path
--help.

2000	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep (15)	Oct (115)	Nov (154)	Dec (258)
2001	Jan (377)	Feb (260)	Mar (249)	Apr (188)	May (152)	Jun (150)	Jul (195)	Aug (202)	Sep (200)	Oct (286)	Nov (242)	Dec (165)
2002	Jan (245)	Feb (241)	Mar (239)	Apr (346)	May (406)	Jun (369)	Jul (418)	Aug (357)	Sep (362)	Oct (597)	Nov (455)	Dec (344)
2003	Jan (446)	Feb (397)	Mar (515)	Apr (524)	May (377)	Jun (387)	Jul (532)	Aug (364)	Sep (294)	Oct (352)	Nov (295)	Dec (327)
2004	Jan (416)	Feb (318)	Mar (324)	Apr (249)	May (259)	Jun (218)	Jul (212)	Aug (259)	Sep (158)	Oct (162)	Nov (214)	Dec (169)
2005	Jan (111)	Feb (165)	Mar (199)	Apr (147)	May (131)	Jun (163)	Jul (235)	Aug (136)	Sep (84)	Oct (88)	Nov (113)	Dec (100)
2006	Jan (85)	Feb (119)	Mar (33)	Apr (31)	May (56)	Jun (68)	Jul (18)	Aug (62)	Sep (33)	Oct (55)	Nov (19)	Dec (40)
2007	Jan (22)	Feb (49)	Mar (34)	Apr (51)	May (66)	Jun (43)	Jul (116)	Aug (57)	Sep (70)	Oct (69)	Nov (97)	Dec (86)
2008	Jan (32)	Feb (47)	Mar (106)	Apr (67)	May (28)	Jun (39)	Jul (31)	Aug (25)	Sep (18)	Oct (25)	Nov (5)	Dec (21)
2009	Jan (33)	Feb (27)	Mar (27)	Apr (22)	May (22)	Jun (10)	Jul (17)	Aug (9)	Sep (21)	Oct (13)	Nov (4)	Dec (11)
2010	Jan (10)	Feb (8)	Mar (4)	Apr (1)	May	Jun (2)	Jul	Aug (1)	Sep (8)	Oct (26)	Nov (9)	Dec (1)
2011	Jan (21)	Feb (16)	Mar (4)	Apr (19)	May (26)	Jun (9)	Jul (6)	Aug	Sep (4)	Oct (3)	Nov (2)	Dec (1)
2012	Jan (4)	Feb (7)	Mar (4)	Apr	May (1)	Jun (10)	Jul (1)	Aug (1)	Sep (18)	Oct (3)	Nov (1)	Dec (1)
2013	Jan (4)	Feb (2)	Mar (15)	Apr (6)	May (1)	Jun (3)	Jul (1)	Aug (2)	Sep (4)	Oct	Nov (9)	Dec
2014	Jan (4)	Feb (1)	Mar	Apr	May	Jun	Jul (5)	Aug (4)	Sep	Oct (2)	Nov (1)	Dec (4)
2015	Jan (2)	Feb (3)	Mar (1)	Apr (2)	May (1)	Jun (2)	Jul	Aug (1)	Sep (2)	Oct (9)	Nov (35)	Dec (6)
2016	Jan (7)	Feb (10)	Mar (10)	Apr (9)	May (13)	Jun (9)	Jul (1)	Aug (3)	Sep (3)	Oct (1)	Nov (1)	Dec
2017	Jan	Feb	Mar	Apr	May	Jun (1)	Jul	Aug	Sep	Oct	Nov	Dec
2018	Jan	Feb	Mar (1)	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2019	Jan (1)	Feb	Mar	Apr (2)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2020	Jan (1)	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

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

Open Source C & C++ IDE for Windows

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