Softpanorama
(slightly skeptical) Open Source Software Educational Society

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

Google   


Softpanorama C bulletin, 2002

[May 16, 2002] TutorialSearch

Packages beginning with letter C

[Apr 19, 2002]C-Scene Issues 1..9 free C/C++ zine. Nine issues are currently avaiable. Quality varies.  Among papers:

[Mar 4, 2002] Computer Stupidities Programming some revealing fragments of C programs ;-)

[Mar 4, 2002] Are You Ready For C99? A brief look at the most dramatic changes to the C programming language made in the C99 standard.  See also Dennis Ritchie's opinion of the C99 standard

A list of features that should[0] have made it into the C99 standard is available on Thomas Wolf's webpage. Listed below are the changes that most developers would notice or care about at first use.

  1. Increased identifier size limits: specifically 63 significant initial characters in an internal identifier or macro name, 31 significant initial characters in an external identifier, and 4095 characters in a logical source line. These values were 31, 6, and 509, respectively, in C89.

    The small identifier size is the reason so many ANSI functions had terse names (strcpy, strstr, strchr, etc) since the standard only guaranteed that the first six characters would be used to uniquely identify the functions.
     
  2. C++ style/line comments: The characters '//' can now be used to delineate a line of commented text, just like in C++.
     
  3. Macros take variable arguments denoted by elipsees: Function-like macros will accept variable arguments denoted by using the ellipsis (...) notation. For replacement, the variable arguments (including the separating commas) are "collected" into one single extra argument that can be referenced as __VA_ARGS__ within the macro's replacement list.
     
  4. Inline functions: The C language now supports the inline keyword which allows functions to be defined as inline, which is a hint to the compiler that invocations of such functions can be replaced with inline code expansions rather than actual function calls.
     
  5. Restricted pointers: The C language now supports the restrict keyword which allows pointers to be defined as restricted, which is a hint to the compiler to disallow two restricted pointers from being aliases to the same object which allows for certain optimizations when dealing with the said pointers.
     
  6. _Bool Macro: There is a _Bool type which is a actually two valued integer type. True is defined as

    #define true (_Bool)1

    while false is defined as

    #define false (_Bool)0

  7. Variable Declarations can appear anywhere in the code block: No longer do variables have to be defined at the top of the code block.

     
  8. Variable length arrays: These are arrays whose size is determined at runtime.

     
  9. Variable declarations in for loops: Variables can now be declared and initialized in for loops just like in C++ and Java.
     
  10. Named initialization of structs: The members of a struct can now be initialized by name such as is done in the code block below

    struct {float x, y, z;} s = { .y = 1.0, .x = 3.5, .z = 12.8};

  11. New long long type: There is a new type called long long which is at least 64 bits and can be both signed or unsigned. The new suffixes "LL" or "ll" (and "ULL" or "ull") are used for constants of the new long long type.
     
  12. Functions must declare a return value: Function return types no longer defaults to int if the function declares no return type.
     
  13. Last member of a struct may be an incomplete array type. : This is to support the "struct hack" which works on most existing C compilers already. A code example of the struct hack is shown on Thomas's site.
     
  14. Addition of _Complex and _Imaginary number types: A boon for programmers doing any sort of advanced math in their programs.
     
  15. Multiple uses of a type qualifier are ignored after the first occurence: If a type qualifier appears several times (either directly or indirectly through typedefs) in a type specification, it's treated as if it appeared only once. E.g.

    const const int x;

    is the same as

    const int x;

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

You can embed JavaScript-script engine in your C applications By David Wall

You may have been pleased to welcome Microsoft's release of the Windows Script Engine (WSE), which was initially part of the Windows NT 4.0 Option Pack and has been available for use on business operating systems since then. The WSE opens certain aspects of Windows to manipulation via the JScript scripting language, which is very much like JavaScript in many ways. The company added a bunch of objects to represent Windows features, as well.

This was cool, but the greater significance (in my humble opinion) is that Microsoft had made a move toward making JavaScript-like languages the norm for application scripting. Rather than have a whole sheaf of application-specific languages, the move promised to make it easier for us to capitalize on our knowledge of JavaScript for all kinds of fun work.

Netscape saw this as good news as well, and has released the JavaScript API as a C library that may be incorporated, via a header file, in any C application you're writing. In other words, they've put out a file -- a DLL on Windows and a shared library for Unix -- that you can compile into your C applications. You can therefore send whole scripts to the JavaScript engine for processing (it, in effect, instantiates a JavaScript parser instance like the one that's running when your browser is operating). The engine supports scripts that are in compliance with ECMA-262, and with Netscape's JavaScript 1.4 specification.

Best of all, Netscape's C Engine for JavaScript requires no licensing fee. Consider it if you need a user-scriptable application.

Netscape's introductory document on the JavaScript C Engine: http://itw.itworld.com/GoNow/a14724a53277a75978418a3

[Dec 28, 2001] Ch -- an embeddable C Interpreter, C Compiler for C-C++ Developers. See also The Ch Language Environment --- A Review of Ch 2.0 at BYTE.com.  I doubt that Ch can replace a scripting language but you mileage may vary.

[Dec 28, 2001] Digital Mars C and C++ Compilers -- contains free C and C++ compilers and free downloads section.

[Aug 30, 2001] Sun plans release of Forte 3

Sun plans a Sept 10 release of version 3 of Forte for Java, an IDE for Java development. Will support C, C++ and Java.

[Aug 22, 2001] OSNews.com - Exploring the Future of Computing  Interview: Rasterman Speaks of Enlightenment .17

4. Is E17 still based on GTK+? If yes, why did you not choose a C++ API where C++ is known to help a lot when it comes to GUI programming?

The Rasterman: It never was based on gtk+. I use gtk for a few development utils because it's there and works. We have a widget set of our own brewing that uses evas - its an example showcase of how evas can be very powerful - even for an entire widget set. As for c++ - i personally am just not comfortable with it. I come from a background of doing assembly programming. For me C is a very high level language and i just don't feel good about C++. Also the C++ compilers and tool sets for linux are much less mature than their C counterparts - meaning more problems to deal with. You also don't NEED C++ to do good GUI coding. It's a matter of style. e17 has a semi-OO setup. You setup event handlers (think of them as classes) and callbacks (methods if you like) in them - it's a very loose comparison - but it works quite well.

"While we generally think of C as the prototype industrial language -- hard-edged, high-performance, and dangerous-- numerous projects have attempted to wrap C in a more amiable package."

"Among the survivors still in production are: CINT, EiC, elastiC, ICI, LPC, Pike."

"Our survey excludes interpreters not generally available for Unix systems (such as QNC and Think C), those with limited interactivity (the UPS C interpreter), and interpreters that are moribund. We found software product catalogs listing C interpreters that have been orphaned for several years, but all the following systems are in active development."

TheLinuxGurus.org: Teach Yourself C for Linux Programming in 21 Days [Book Review](Jul 04, 2000)
LinuxNewbie.org: Introduction to Programming in C/C++ with Vim (Jul 01, 2000)
IBM developerWorks: The wonders of glib - Making C programming easier(Apr 23, 2000)
dotcomma: Control Flow In C - Loops(Mar 26, 2000)
dotcomma: First Steps With C(Mar 26, 2000)
dotcomma.org: Introduction to C++ Classes for C Programmers(Jan 09, 2000)
Freshmeat: Coding Standards: Good Idea or Subtle Evil?(Jan 08, 2000)
An IRC Tutorial on C Programming(Apr 25, 1999)


Copyright © 1996-2008 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

Standard disclaimer: The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: February 28, 2008