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

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 STL Sample Codes
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX  

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

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

         Reference Books for C++ Standard Template Library

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 

1. Effective STL: 50 Specific Ways to Improve Your Use of the Standard Template Library by Scott Meyers
2. The C++ Standard Library: A Tutorial and Reference by Nicolai M. Josuttis
3. STL Tutorial and Reference Guide: C++ Programming with the Standard Template Library (paperback) (2nd Edition) (C++ in Depth Series) by David R. Musser, Gillmer J. Derge and Atul Saini
4. The C++ Standard Template Library by P.J. Plauger, Alexander Stepanov, Meng Lee and David R. Musser
5. C++ Templates: The Complete Guide by David Vandevoorde and Nicolai M. Josuttis
6. Generic Programming and the STL: Using and Extending the C++ Standard Template Library by Matthew H. Austern
7. Data Structures in C++: Using the Standard Template Library (STL) by Timothy Budd
8. Using the STL: The C++ Standard Template Library by Robert Robson
9. Data Structure Programming: With the Standard Template Library in C++ (Undergraduate Texts in Computer Science) by Joseph Bergin
10. C++ Programmer's Guide to the Standard Template Library by Mark Nelson

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

celcius to fahrenheit conversion in c

/*********************************************************************** * File : temperature-conversion.c * Author : Saurabh Gupta * Desc : c programs convert temperature from degree celsius to * degree fahrenheit * celcius to fahrenheit conversion c code * Source : http://saurabhgupta0527.blogspot.com/p/c.html * Created : PM 10:58 30 October 2011 * Note : ************************************************************************/ #include <stdio.h> int main() { int nCelcius; float fFahrenhrit; printf("Enter temp in degree Celsius : "); scanf("%d",&nCelcius); fFahrenhrit = (float)9/5*nCelcius + 32; printf("temp in deg celsius = %d C and in deg fah = %fF\n",nCelcius,fFahrenhrit); return 0; } /* * OUTPUT * [sgupta@rhel55x86 c]$ gcc temperature-conversion.c -o temperature-conversion [sgupta@rhel55x86 c]$ ./temperature-conversion Enter temp in degree Celsius : 100 temp in deg celsius = 100 C and in deg fah = 212.000000F [sgupta@rhel55x86 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.

See Also 
POSIX Signal Tutorial and example codes

sigtstp handler

/**************************************************************** * Filename : sigtstp.c * Author : Saurabh Gupta * Source : http://saurabhgupta0527.blogspot.com/2011/08/posix-signal-tutorial.html * Desc : How to handle SIGTSTP * SIGTSTP in unix * handling SIGTSTP * sigtstp example * Created : PM 09:41 29 October 2011 * Note : ****************************************************************/ #include <signal.h> #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <errno.h> /* for definition of errno */ #include <stdarg.h> /* ISO C variable aruments */ #include <string.h> #define BUFFSIZE 1024 #define MAXLINE 4096 /* max line length */ static void sig_tstp(int); void err_sys(const char *, ...); static void err_doit(int, int, const char *, va_list); int main(void) { int n; char buf[BUFFSIZE]; /* * Only catch SIGTSTP if we're running with a job-control shell. */ if (signal(SIGTSTP, SIG_IGN) == SIG_DFL) { signal(SIGTSTP, sig_tstp); } while ((n = read(STDIN_FILENO, buf, BUFFSIZE)) > 0) if (write(STDOUT_FILENO, buf, n) != n) { err_sys("write error"); } if (n < 0) { err_sys("read error"); } exit(0); } static void sig_tstp(int signo) { /* signal handler for SIGTSTP */ sigset_t mask; /* * Unblock SIGTSTP, since it's blocked while we're handling it. */ sigemptyset(&mask); sigaddset(&mask, SIGTSTP); sigprocmask(SIG_UNBLOCK, &mask, NULL); signal(SIGTSTP, SIG_DFL); /* reset disposition to default */ kill(getpid(), SIGTSTP); /* and send the signal to ourself */ /* * we won't return from the kill until we're continued */ signal(SIGTSTP, sig_tstp); /* reestablish signal handler */ } /* * Fatal error related to a system call. * Print a message and terminate. */ void err_sys(const char *fmt, ...) { va_list ap; va_start(ap, fmt); err_doit(1, errno, fmt, ap); va_end(ap); exit(1); } /* * Print a message and return to caller. * Caller specifies "errnoflag". */ static void err_doit(int errnoflag, int error, const char *fmt, va_list ap) { char buf[MAXLINE]; vsnprintf(buf, MAXLINE, fmt, ap); if (errnoflag) { snprintf(buf+strlen(buf), MAXLINE-strlen(buf), ": %s", strerror(error)); } strcat(buf, "\n"); fflush(stdout); /* in case stdout and stderr are the same */ fputs(buf, stderr); fflush(NULL); /* flushes all stdio output streams */ }
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:

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

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.

Example

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

handling SIGTSTP signals

See Also 
POSIX Signal Tutorial and example codes

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.

Example:

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.

sleep function example in c

See Also 
POSIX Signal Tutorial and example codes

sleep function example in c

/**************************************************************** * Filename : sleep.c * Author : Saurabh Gupta * Source : http://saurabhgupta0527.blogspot.com/2011/08/posix-signal-tutorial.html * Desc : Implementation of POSIX sleep * sleep function in unix * sleep function example * Created : AM 10:24 27 October 2011 * Note : ****************************************************************/ #include <signal.h> #include <stdio.h> #include <stdlib.h> #include <unistd.h> static void sig_alrm(int signo) { /* * nothing to do, just returning wakes up sigsuspend() */ } unsigned int sleep(unsigned int nsecs) { struct sigaction newact, oldact; sigset_t newmask, oldmask, suspmask; unsigned int unslept; /* * set our handler, save previous information */ newact.sa_handler = sig_alrm; sigemptyset(&newact.sa_mask); newact.sa_flags = 0; sigaction(SIGALRM, &newact, &oldact); /* * block SIGALRM and save current signal mask */ sigemptyset(&newmask); sigaddset(&newmask, SIGALRM); sigprocmask(SIG_BLOCK, &newmask, &oldmask); alarm(nsecs); suspmask = oldmask; sigdelset(&suspmask, SIGALRM); // make sure SIGALRM isn't blocked sigsuspend(&suspmask); // wait for any signal to be caught /* * some signal has been caught, SIGALRM is now blocked */ unslept = alarm(0); sigaction(SIGALRM, &oldact, NULL); // reset previous action /* * reset signal mask, which unblocks SIGALRM */ sigprocmask(SIG_SETMASK, &oldmask, NULL); return(unslept); }

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.

new projects in C/C++

abort example c

/**************************************************************** * Filename : abort.c * Author : Saurabh Gupta * Source : http://saurabhgupta0527.blogspot.com/2011/08/posix-signal-tutorial.html * Desc : Implementation of POSIX.1 abort * abort function in unix * abort function example * Created : AM 07:37 26 October 2011 * Note : ****************************************************************/ #include <signal.h> #include <stdio.h> #include <stdlib.h> #include <unistd.h> /* * POSIX-style abort() function */ void abort(void) { sigset_t mask; struct sigaction action; /* * Caller can't ignore SIGABRT, if so reset to default. */ sigaction(SIGABRT, NULL, &action); if (action.sa_handler == SIG_IGN) { action.sa_handler = SIG_DFL; sigaction(SIGABRT, &action, NULL); } if (action.sa_handler == SIG_DFL) { fflush(NULL); /* flush all open stdio streams */ } /* * Caller can't block SIGABRT; make sure it's unblocked. */ sigfillset(&mask); sigdelset(&mask, SIGABRT); /* mask has only SIGABRT turned off */ sigprocmask(SIG_SETMASK, &mask, NULL); kill(getpid(), SIGABRT); /* send the signal */ /* * If we're here, process caught SIGABRT and returned. */ fflush(NULL); /* flush all open stdio streams */ action.sa_handler = SIG_DFL; sigaction(SIGABRT, &action, NULL); /* reset to default */ sigprocmask(SIG_SETMASK, &mask, NULL); /* just in case ... */ kill(getpid(), SIGABRT); /* and one more time */ exit(1); /* this should never be executed ... */ } int main () { abort (); return 0; } /** * OUTPUT * [sgupta@rhel55x86 signal]$ gcc -o abort abort.c [sgupta@rhel55x86 signal]$ ./abort Aborted [sgupta@rhel55x86 signal]$ */See Also
POSIX Signal Tutorial and example codes

abort function in unix

/*
 * abort function in c

 */

abort function causes abnormal program termination

#include <stdlib.h>

void abort(void);

Return:

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

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

UNIX and AIX concepts