Monday, October 31, 2011

standard template library

standard template library c++

The Standard Template Library – STL provides a set of C++ container classes and template algorithms designed to work together to produce a wide range of useful functionality. Though only a small number of container classes are provided, they include the most widely useful containers, such as vectors, lists, sets and maps. The template algorithm components include a broad range of fundamental algorithms for the most common kinds of data manipulations, such as searching, sorting, and merging.

The critical difference between STL and all other C++ container class libraries is that STL algorithms are generic: every algorithm works on a variety of containers, including built-in types, and many work on all containers. Initially we will look at why and how of generic algorithms and other key concepts that give STL many advantages over other software libraries. One of the most important concepts of STL is the way generic algorithms are defined in terms of iterators, which generalize C/C++ pointers, together with the way different kinds of iterators are defined for traversing the different kind of containers.  Beside containers, generic algorithms, and iterators, STL also provides function objects which generalize ordinary C/C++ functions and allow other components to be efficiently adapted to a variety of tasks. The library also includes various other kinds of adapters for changing the interfaces of containers, iterators, or functions objects. Storage management in STL is controlled by yet another component type, allocators. All these components are discussed in the STL overview in my coming posts.

STL is only part of a large software library, the C++ standard library approved by the ANSI/ISO C++ committee in the International Standard for C++. Nevertheless, STL remains a coherent framework of fine-grained, interchangeable components that deserve treatment separate from the rest of the C++ Standard Library.

Following topic are under STL,

1. About STL

2. make_pair in stl

3. Containers
   a. Sequence Container
      a1. vector
      a2. deque
      a3. list
   b. Associative Container
   c. container adaptors

4. Iterators 
   a. Examples of Using Associative Containers
      a1. Examples of Using Sets & Multisets
      a2. Examples of Using Map & Multimaps
      a3. Maps as Associative Arrays
   b. Iterator Category
      b1. Bidirectional Operator
      b2. Random Access Operator

5. Algorithm
   a. STL Ranges

6. Iterator Adapters
   a. Insert iterators
   b. Stream iterators
   c. Reverse iterators

7. Manipulating Algorithm
   a. Removing Elements

8. Functions as Algorithm Arguments
   a. Examples of using Functions as Algorithm Arguments
   b. predicates
      b1. unary predicate
      b2. binary predicate

9. Function Objects 
   a. What are Function Objects
   b. Advantage of Function Objects
   c. Predefined Function Objects

10. Container Elements
   a. Requirements for container elements
   b. Value semantics or Reference Semantics

11. Errors and Exceptions Inside the STL
   a. Error Handling
   b. Exception Handling

12. STL Containers

   a. Common Container Abilities and Operations
     a1. Common Container Abilities
     a2. Common Container Operations

   b. Vectors
     b1. Abilities of Vectors
     b2. Vector Operations
     b3. Using Vectors as Ordinary Arrays
     b4. Examples of Using Vectors
     b5. Class vector<bool>

   c. Deques
     c1. Abilities of Deques
     c2. Deque Operation
     c3. Example of Using Deque

  d.  Lists
     d1. Advantage of Lists
     d2. List Operations
     d3. Example using List

 STL Sample Codes

  1. vector
  2. deque
  3. list
  4. Iterators 
  5. set
  6. multiset
  7. map
  8. multimap
  9. Maps as Associative Arrays
  10. insert iterator
  11. stream iterator
  12. reverse iterator
  13. list remove  
  14. for_each
  15. transform algorithm
  16. find_if example (unary predicate)
  17. binary predicate
  18. using function object
  19. predefined function objects
         Reference Books for C++ Standard Template Library

    Sunday, October 30, 2011

    celcius to fahrenheit conversion in c

    See also
    Other popular tricky C Sample Codes and language Concept.

    Signal Mappings

    Solaris provides a couple of functions to map a signal number to a signal name and vice versa.

    #include <signal.h>

    int sig2str(int signo, char *str);
    int str2sig(const char *str, int *signop);

    Both return: 0 if OK, 1 on error

    These functions are useful when writing interactive programs that need to accept and print signal names and numbers.

    The sig2str function translates the given signal number into a string and stores the result in the memory pointed to by str. The caller must ensure that the memory is large enough to hold the longest string, including the terminating null byte. Solaris provides the constant SIG2STR_MAX in <signal.h> to define the maximum string length. The string consists of the signal name without the "SIG" prefix. For example, translating SIGKILL would result in the string "KILL" being stored in the str memory buffer.

    The str2sig function translates the given name into a signal number. The signal number is stored in the integer pointed to by signop. The name can be either the signal name without the "SIG" prefix or a string representation of the decimal signal number (i.e., "9").

    Note that sig2str and str2sig depart from common practice and don't set errno when they fail.

    Saturday, October 29, 2011

    sigtstp handler

    See Also 
    POSIX Signal Tutorial and example codes

    job control signals

    job control signals unix:

    Of the signals shown in signal concept, POSIX.1 considers six to be job-control signals:

    Child process has stopped or terminated.
    Continue process, if stopped.
    Stop signal (can't be caught or ignored).
    Interactive stop signal.
    Read from controlling terminal by member of a background
    process group.
    Write to controlling terminal by member of a background process

    Except for SIGCHLD, most application programs don't handle these signals: interactive shells usually do all the work required to handle these signals. When we type the suspend character (usually Control-Z), SIGTSTP is sent to all processes in the foreground process group. When we tell the shell to resume a job in the foreground or background, the shell sends all the processes in the job the SIGCONT signal. Similarly, if SIGTTIN or SIGTTOU is delivered to a process, the process is stopped by default, and the job-control shell recognizes this and notifies us.

    An exception is a process that is managing the terminal: the vi(1) editor, for example. It needs to know when the user wants to suspend it, so that it can restore the terminal's state to the way it was when vi was started. Also, when it resumes in the foreground, the vi editor needs to set the terminal state back to the way it wants it, and it needs to redraw the terminal screen. We see how a program such as vi handles this in the example that follows.

    There are some interactions between the job-control signals. When any of the four stop signals (SIGTSTP, SIGSTOP, SIGTTIN, or SIGTTOU) is generated for a process, any pending SIGCONT signal for that process is discarded. Similarly, when the SIGCONT signal is generated for a process, any pending stop signals for that same process are discarded.

    Note that the default action for SIGCONT is to continue the process, if it is stopped; otherwise, the signal is ignored. Normally, we don't have to do anything with this signal. When SIGCONT is generated for a process that is stopped, the process is continued, even if the signal is blocked or ignored.


    The program below demonstrates the normal sequence of code used when a program handles job control. This program simply copies its standard input to its standard output, but comments are given in the signal handler for typical actions performed by a program that manages a screen. When the program starts, it arranges to catch the SIGTSTP signal only if the signal's disposition is SIG_DFL. The reason is that when the program is started by a shell that doesn't support job control (/bin/sh, for example), the signal's disposition should be set to SIG_IGN. In fact,
    the shell doesn't explicitly ignore this signal; init sets the disposition of the three job-control signals (SIGTSTP, SIGTTIN, and SIGTTOU) to SIG_IGN. This disposition is then inherited by all login shells. Only a job-control shell should reset the disposition of these three signals to SIG_DFL.

    When we type the suspend character, the process receives the SIGTSTP signal, and the signal handler is invoked. At this point, we would do any terminal-related processing: move the cursor to the lowerleft corner, restore the terminal mode, and so on. We then send ourself the same signal, SIGTSTP, after resetting its disposition to its default (stop the process) and unblocking the signal. We have to unblock it since we're currently handling that same signal, and the system blocks it automatically while it's being caught. At this point, the system stops the process. It is continued only when it receives (usually from the job-control shell, in response to an interactive fg command) aSIGCONT signal. We don't catch SIGCONT. Its default disposition is to continue the stopped process; when this happens, the program continues as though it returned from the kill function. When the program is continued, we reset the disposition for the SIGTSTP signal and do whatever terminal processing we want (we could redraw the screen, for example).

    Friday, October 28, 2011

    sleep function in c

    sleep Function

    We've used the sleep function in numerous examples throughout the text, and we showed two flawed implementations of it below

    #include <unistd.h>

    unsigned int sleep(unsigned int seconds);

    Returns: 0 or number of unslept seconds
    This function causes the calling process to be suspended until either
    1. The amount of wall clock time specified by seconds has elapsed. 
    2. A signal is caught by the process and the signal handler returns.
    As with an alarm signal, the actual return may be at a time later than requested, because of other system activity.

    In case 1, the return value is 0. When sleep returns early, because of some signal being caught (case 2), the return value is the number of unslept seconds (the requested time minus the actual time slept).

    Although sleep can be implemented with the alarm function, this isn't required. If alarm is used, however, there can be interactions between the two functions. The POSIX.1 standard leaves all these interactions unspecified. For example, if we do an alarm(10) and 3 wall clock seconds later do a sleep(5), what happens? The sleep will return in 5 seconds (assuming that some other signal isn't caught in that time), but will another SIGALRM be generated 2 seconds later? These details depend on the implementation.

    Solaris 9 implements sleep using alarm. The Solaris sleep(3) manual page says that a
    previously scheduled alarm is properly handled. For example, in the preceding scenario, before sleep returns, it will reschedule the alarm to happen 2 seconds later; sleep returns 0 in this case. (Obviously, sleep must save the address of the signal handler for SIGALRM and reset it before returning.) Also, if we do an alarm(6) and 3 wall clock seconds later do a sleep(5), the sleep returns in 3 seconds (when the alarm goes off), not in 5 seconds. Here, the return value from sleep is 2 (the number of unslept seconds).

    FreeBSD 5.2.1, Linux 2.4.22, and Mac OS X 10.3, on the other hand, use another technique: the delay is provided by nanosleep(2). This function is specified to be a high-resolution delay by the real-time extensions in the Single UNIX Specification. This function allows the implementation of sleep to be independent of signals.

    For portability, you shouldn't make any assumptions about the implementation of sleep, but if you have any intentions of mixing calls to sleep with any other timing functions, you need to be aware of possible interactions.


    Figure below shows an implementation of the POSIX.1 sleep function.  This function handles signals reliably, avoiding the race condition in the earlier implementation. We still do not handle any interactions with previously set alarms. (As we mentioned, these interactions are explicitly undefined by POSIX.1.)

    It takes more code to write this reliable implementation than what is shown in Figure below. We don't use any form of nonlocal branching, so there is no effect on other signal handlers that may be executing when the SIGALRM is handled.

    Thursday, October 27, 2011

    sleep function example in c

    Wednesday, October 26, 2011

    c++ new projects

    C / C++ new projects,

    all the students who are really looking for the newly developed in C/C++ for UNIX and windows platform can go through here.  All the projects are based on the new concepts and self written by me. Please go through the below link to see the list. There are lots of new development work is going on that will keep on updating.

    abort example c

    See Also
    POSIX Signal Tutorial and example codes

    Tuesday, October 25, 2011

    abort function in unix

     * abort function in c
    abort function causes abnormal program termination

    #include <stdlib.h>

    void abort(void);

    This function never returns

    This function sends the SIGABRT signal to the caller. (Processes should not ignore this signal.) ISO C states that calling abort will deliver an unsuccessful termination notification to the host environment by calling raise(SIGABRT).

    ISO C requires that if the signal is caught and the signal handler returns, abort still doesn't return to its caller. If this signal is caught, the only way the signal handler can't return is if it calls exit, _exit, _Exit, longjmp, or siglongjmp. (Section 10.15 discusses the differences between longjmp and siglongjmp.) POSIX.1 also specifies that abort overrides the blocking or ignoring of the signal by the process.

    The intent of letting the process catch the SIGABRT is to allow it to perform any cleanup that it wants to do before the process terminates. If the process doesn't terminate itself from this signal handler, POSIX.1 states that, when the signal handler returns, abort terminates the process.

    The ISO C specification of this function leaves it up to the implementation as to whether output streams are flushed and whether temporary files are deleted. POSIX.1 goes further and requires that if the call to abort terminates the process, then the effect on the open standard I/O streams in the process will be the same as if the process had called fclose on each stream before terminating.

    Earlier versions of System V generated the SIGIOT signal from the abort function. Furthermore, it was possible for a process to ignore this signal or to catch it and return from the signal handler, in which case abort returned to its caller.

    4.3BSD generated the SIGILL signal. Before doing this, the 4.3BSD function unblocked the signal and reset its disposition to SIG_DFL (terminate with core file). This prevented a process from either ignoring the signal or catching it.

    Historically, implementations of abort differ in how they deal with standard I/O streams. For defensive programming and improved portability, if we want standard I/O streams to be flushed, we specifically do it before calling abort.

    Since most UNIX System implementations of tmpfile call unlink immediately after creating the file, the ISO C warning about temporary files does not usually concern us.

    See Also 
    POSIX Signal Tutorial and example codes

    Sunday, October 23, 2011

    aix file system difference

    Table below displays some of the differences between JFS and JFS2 file systems.

    JFS and JFS2 file system can coexist on the same systems.

    If you to migrate data from a JFS file system to a JFS2 file system you have to back up the JFS file system and restore the data on the JFS2 file systems.

    See Also