Thread: Fw: [Dev-C++] Deliberate crashes - more information
Open Source C & C++ IDE for Windows
Brought to you by:
claplace
Menu
▾
▴
dev-cpp-users
|
From: Bob W. <bo...@ph...> - 2002-04-08 23:50:32
|
>> 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 |
|
From: Ioannis V. <no...@ho...> - 2002-04-08 23:59:44
|
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. |
|
From: Bob W. <bo...@ph...> - 2002-04-09 01:20:07
|
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 |
|
From: Ioannis V. <no...@ho...> - 2002-04-09 12:04:16
|
-----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 |
|
From: Bob W. <bo...@ph...> - 2002-04-09 14:03:35
|
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
|
|
From: Ioannis V. <no...@ho...> - 2002-04-09 16:24:47
|
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
|
|
From: Bob W. <bo...@ph...> - 2002-04-09 18:20:40
|
MessageIoannis, I think the bullet-proof code is a thing that must be taught after the = basics. Yes, I know that you believe that, and, while I agree that any in-depth = study of bullet proofing should wait until the student knows the = constructs of the language, bullet proofing should not be ignored as the = student learns the basics of the language.=20 Regards, Bob |
