Softpanorama (slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-)

Softpanorama C++ bulletin, 2002

[Dec 26, 2002] [PDF] Sample Chapter  (Chapter 26: Program Design ) from Practical C++ Programming, 2nd Edition By Steve Oualline, 2nd Edition December 2002  ISBN 0-596-00419-2

[Jun 7, 2002] C-C++ Tutorials & C# Tutorials - justPhukit.com -- nice collection of C++ papers and tutorials

[Mar 4, 2002] How to avoid Memory Leakage

Errors and complex systems
Any developer writing server applications, or other programs running continuously for a longer periods of time, knows how frustrating it can be with processes slowly allocating more and more memory until some other program finally crashes 3 days later after running out of memory. Memory leakage is probably one of the most difficult programming problems to solve, because you cannot easily search thousands of lines of code for a complex logical error that might cause a problem when some unlikely event occurs. If your application interacts with other programs as well, you might not even have any source code to search. If you are really unfortunate, a small error in your application could activate a buggy piece of code in some other program, and eventually that other program might crash the entire system after allocating all available memory. How are you supposed to find out what really happened?

Debugging and Testing
Writing computer programs is not a simple matter. Computers can execute millions of instructions in one second, but they still don't know what to do if you tell them to "draw a circle". Fortunately you can easily make any computer draw a circle by combining a number of simpler instructions. By using even more instructions you can make the computer do even more impressive things, like drawing a house or decompressing a live video stream from a mars. The only problem is, the more instructions you add, the more likely you are to make an error. With modern programs consisting of thousands or millions of lines of code, errors are pretty much unavoidable. This wouldn't be a problem at all if there were only syntactic errors, since these are easily detected by the compiler, but there are also logical errors (bugs) that will pass right through your compiler without a single warning. Many errors are not even serious enough to cause any problems on their own, but when you combine a few of these errors, you get to spend hours reading your own code, trying to figure out what it really does. So how can we find the errors without spending to many hours on every line of code? The answer is pretty obvious. We run the program! If there are any bugs, they will probably show up after running the program for a while. Although this is a very efficient strategy, there are some errors that don't affect the user-interface or any other observable part of the program directly. These errors are much harder to find, since it may take hours or even days before they have any effects on the user-interface. To find these errors without spending hours or days on each test-update cycle, we need to keep track of some more abstract properties of the program, like memory and cpu-usage. By monitoring these properties for some time, you will be able to find trends and predict problems long before you actually get an error message.

[Feb 2, 2002] Re- What is wrong with OO -

Search Result 128 From: Alexander E. Kopilovitch (aek@pcaek.spb.su) Subject: Re: What is wrong with OO ? Newsgroups: comp.lang.c++   View: Complete Thread (549 articles) | Original Format Date: 1997/02/15

In  <E5M1E4.Ks8@mv.mv.com>  ENGR@GSSI.MV.COM (Michael Furman) writes:

>>C++ has no substantial ability to create abstractions: it does not implement
>>the concept of coroutines.
>
>That is very unusual opinion. Do you think that "coroutines" just the same
>as "abstractions"?
No. An abstraction of "rectangle" seems to have nothing common with
coroutines.

> Or that no abstraction can be created without coroutine support?
Again no. There are many abstractions that can be created without any need of
coroutines. Moreover, there are no such abstractions that require coroutines
as absolutely necessary tool. This is somewhat analogous to recursion in
conventional programming: this mechanism isn't absolutely necessary for any
case (because recursion always can be replaced with suitable iteration), but
it is very useful in some situations and because of this it becomes critically
important for some (parts of) applications.

>Could you elaborate please?
Well, I'll try. Classes without coroutines are "non-programmable" components.
Similar to hardware devices, software components may be programmable or not.
Dumb hardware device may have several switches, but it does not make it
true programmable. At the other hand, we have programmed hardware devices
which are in general much more flexible and more integrated. C++ classes
tend to be "dumb software components" because they are not programmable
inside them. Consequently, to be really useful, C++ classes must be combined
with each other, consituting relatively large construction, called "library"
(which is in turn analogous to boards with many circuits inside of computers
in sixties). It is true that C++ (in its abstraction-oriented part) is the
language suitable for creating those libraries, but it isn't so suitable for
design of programs which are not libraries or to build applications which are
not based on one of existing libraries.

>>Its predecessor - Simula - has this capability and
>>thus may be used for abstraction creation, but C++ did not inherit this
>>critical capability.
>
>Coroutines were included into Simuls-67 because this language was designed
>for simulation.
The matter is that huge part of programming in general is some kind of
simulation. Not all programming, but huge part of it. And don't tell me
please that it is another very unusual opinion - better take a look at
M. A. Jackson's book "System Development", for example.

> Mechanism like coroutines (nowadays we prefer to talk about
>thread rather then coroutines, but it does not make difference)
Threads and coroutines aren't exactly same thing - there is the difference:
when we speak about "coroutines" which are parts of a single program, we
mean that they are executed in turn, not concurrently while term "thread"
doesn't determine (in general) the possibility of concurrent execution, and
in many cases threads are implemented so that their concurrent execution is
permitted and desirable. Therefore, threads are in general significantly more
heavier thing. You may try to imagine a set of mutually recursive threads and
you'll get sense of distinction.

> is very helpful for simulation (and for real embedded software).
>
>C++ was designed as a language for all kind of software. And features that
>are not needed for all and may be easyly implemented as external libraries
>was not included in the C++ language itself (IMO, it was very reasonoble).
C++ author(s) and promoters had their reasons. And they succeeded - we have
many huge class libraries now.

>There are number of thread-libraries that give you what you need.
Do you think that it is very convinient to create abstractions using these
libraries? Do you think that you can successfully and easily use these
libraries along with abstraction-oriented features of C++?

>>  Therefore, one may consider C++ classes as structures containing common dat
>>a along with pointers to functions - there is no other environment associated
>>with an object of a class in C++.
>
>Thet is not true even technically. You forgot about inheritance (including
>multiple and virtual), virtual / inline / static member functions.
I'm sorry, but I didn't forgot anything of these objectware. If you mean
that object data may contain not only direct pointers to functions, but
also indirect ones - this is true, but this do not make significant difference.

>And what is the point - you'd better consider C++ class as a set of bits.
And computer - as a set of atoms.

>>> Most C programmers don't seem to know what abstraction is
>>>about, or understand the importance of separating interface specification
>>>from implementation. Unfortunately, far too many C++ programmers, with
>>>the above simplistic view of C, carry this style into their C++ code.
>>I think, that it is true, but at the same time I think that the reason is
>>that abstractions which can be created with C++ are too weak and incomplete
>>(as abstractions) and therefore cannot attract attention of many programmers.
>
>That is also a very untraditional view. Could you prove it?
I think that real, observable situation permits to assume it. I cannot set a
proving experiment and I don't know any other methods for proving facts about
real life.


Alexander Kopilovitch                      aek@pcaek.spb.su
Saint-Petersburg
Russia

Last modified: February 28, 2008