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 ([email protected]) Subject: Re: What is wrong with OO ? Newsgroups: comp.lang.c++   View: Complete Thread (549 articles) | Original Format Date: 1997/02/15

In  <[email protected]>  [email protected] (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                      [email protected]
Saint-Petersburg
Russia

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019