Showing posts with label c. Show all posts

Find and replace a string in c++

This can be handy many a times when you are working on a C++ application. There is a no direct method in the standard to do the same except when you are using a boost library. Below is a simple function that I use regularly in my applications which comes in handy for me all the time 
template<class T> int inline findAndReplace(T& source, const T& find, const T& replace) { int num=0; int fLen = find.size(); int rLen = replace.size(); for (int pos=0; (pos=source.find(find, pos))!=T::npos; pos+=rLen) { num++; source.replace(pos, fLen, replace); } return num; }
Read More

What is Undefined Behavior?

In computer programming, undefined behavior refers to computer code whose behavior is unpredictable. It is a feature of some programming languages—most famously C.[1] In these languages, to simplify the specification and allow some flexibility in implementation, the specification leaves the results of certain operations specifically undefined, meaning that the programmer can't predict what will happen.

For example, in C the use of any automatic variable before it has been initialized yields undefined behavior, as would division by zero or indexing an array outside of its defined bounds (see buffer overflow). This specifically frees the compiler to do whatever is easiest or most efficient, should such a program be submitted. In general, any behavior afterwards is also undefined. In particular, it is never required that the compiler diagnose undefined behavior — therefore, programs invoking undefined behavior may appear to compile and even run without errors at first, only to fail on another system, or even on another date. When an instance of undefined behavior occurs, so far as the language specification is concerned anything could happen, maybe nothing at all. In particular, anything may include apparently-impossible behavior because the compiler has made assumptions that lead to erroneous code generation that does not match the source code.

Under some circumstances there can be specific restrictions on undefined behavior. For example, the instruction set specifications of a CPU might leave the behavior of some forms of an instruction undefined, but if the CPU supports memory protection then the specification will probably include a blanket rule stating that no user-accessible instruction may cause a hole in the operating system's security; so an actual CPU would be permitted to corrupt any or all user registers in response to such an instruction but would not be allowed to, for example, switch into supervisor mode.
In C and C++, implementation-defined behavior is also defined which requires the implementation to document what it does, thus more restrictive than undefined behavior.

Examples in C and C++ :

Attempting to modify a string literal causes undefined behavior:[2]
char * p = "wikipedia"; // ill-formed C++11, deprecated C++98/C++03 p[0] = 'W'; // undefined behaviour
One way to prevent this is defining it as an array instead of a pointer.
char p[] = "wikipedia"; /* RIGHT */ p[0] = 'W';
In C++ one can use STL string as follows. 
std::string s = "wikipedia"; /* RIGHT */ s[0] = 'W';
Division by zero results in undefined behavior:[3] 
return x/0; // undefined behavior
Certain pointer operations may result in undefined behavior:[4] 
int arr[4] = {0, 1, 2, 3}; int* p = arr + 5; // undefined behavior
Reaching the end of a value-returning function (other than main()) without a return statement may result in undefined behavior: 
int f() { } /* undefined behavior */
The C Programming Language cites the following examples of code that have undefined behavior in Section 2.12: The order in which function arguments are evaluated is not specified, so the statement 
printf("%d %d\n", ++n, power(2, n)); /* WRONG */
results in undefined behavior. The following statement is ambiguous as it is not clear whether the array index is the old value of i or the new. 
 a[i] = i++;
This results in undefined behavior.
Read More

Fork in C

Did you try this program:

#include &ltstdio.h&gt #include &ltsys/types.h&gt #include &ltunistd.h&gt int main(void) { int i; for(i = 0; i < 2; i++) { fork(); printf("."); } return 0; }

How many dots will this program print.
If you analyse and count , you will come up with a total of 6 dots.
But in real after you execute you will see not 6 but 8 dots printed on the console.

The reason for this is :
So, at first, there is one process. That creates a second process, both of which print a dot and loop. On their second iteration, each creates another copy, so there are four processes print a dot, and then exit. So we can easily account for six dots, like you expect.

However, what printf() really does is buffer its output. So the first dot from when there were only two processes does not appear when written. Those dots remain in the buffer—which is duplicated at fork(). It is not until the process is about to exit that the buffered dot appears. Four processes printing a buffered dot, plus the new one gives 8 dots.

If you wanted to avoid that behavior, call fflush(stdout); after printf().
Read More

How does free work in C

This is very important for every C/C++ programmer to know. And most of the interviewers too ask this question.I myself had asked in many interviews, but hardly I can get a good response from the people. So I thought it would be better to post it here so that people will get to know.
char *ptr =malloc(5*sizeof(char));
The above statement will allocate 5 bytes of memory for the pointer ptr on HEAP. Most of the people that I came across specially graduates think that memory is allocated on stack which is actually not true.

So after you use ptr in your code and get the task done you have to delete or free the memory.so you write this for it.
free(ptr);
Remember, you are not passing 5 bytes to free as an argument, but how come free function know that it has to free 5 bytes? When you call malloc(), you specify the amount of memory to allocate. The amount of memory actually used is slightly more than this, and includes extra information that records (at least) how big the block is. You can't (reliably) access that other information - and nor should you . When you call free(), it simply looks at the extra information to find out how big the block is.

This is the logic behind this magic(at least for a programmer this is a magic provided by the standard).
also see the link in c-faqs:
How does free know how many bytes to free?
Same principle is followed for delete and new.
Read More

Hiding a standard library function in c++

I have a function abs in one of the libraries and I wanted to use that function by linking to that library.But I am facing this error below:
function abs used is #define abs(x) (x &gt; 0) ? x : -(x).
This is obviously from the standard includes that I used. So I found a some very nice ways to overcome this problem :

  • Wrapping the function name abs in parenthesis has resolved the problem right away.
    (abs)(arguments)

  • Using the preprocessor directives Before you call the function abc in the library.
    #undef abs
Read More

Print the next power of 2 for a given number

Below is the program that I have written for printing the next power of 2 for a given number.
The code mostly uses the bitwise operations in c/c++.
 int main () { int num; scanf("%d",&num); int count=0; if(!((num != 1) && (num&(num-1)))) { printf("%d is already a power of two.\n",num); printf("%d is next number power of 2.\n",num*2); } else { while((num>>=1)&&(++count)); printf("%0.0f",pow(2.0,count+1)); } }
Read More

Executing shell command in c/c++ and parsing the output

Often we need to execute some shell command and get the output of that shell command in c.
system will simply execute the shell command but ther is no way using it for fetching its output.
below is the way where we can execute the command and also get its output into a c/c++ buffer.
FILE* pipe = popen("your shell command here", "r"); if (pipe) { char buffer[128]; while(!feof(pipe)) { if(fgets(buffer, 128, pipe) != NULL){} } pclose(pipe); buffer[strlen(buffer)-1] = '\0'; }
Read More

Return type of malloc 

 int *ptr = malloc(sizeof(int)*length); int *ptr = (int *)malloc(sizeof(int)*length);
Which one is correct?
Its the first one. You don't cast the result, since: 
 It is unnecessary, as void * is automatically and safely promoted to any other pointer type in this case. It can hide an error, if you forgot to include <stdlib.h>. This can cause crashes, in the worst case. It adds clutter to the code, casts are not very easy to read (especially if the pointer type is long). It makes you repeat yourself, which is generally bad.
As a clarification, note that I said "you don't cast", not "you don't need to cast". In my opinion, it's a failure to include the cast, even if you got it right. There are simply no benefits to doing it, but a bunch of potential risks, and including the cast indicates that you don't know about the risks. Also note, as commentators point out, that the above changes for straight C, not C++. I very firmly believe in C and C++ as separate languages.
Read More

Delete comments from a C/C++ source file

Solution can be many but below is a good one:
cpp -P -fpreprocessed t.c | grep -v "^[ \t]*$"
another is a complex one . For example, this one-liner
perl -0777 -pe 's{/\*.*?\*/}{}gs' foo.c
will work in many but not all cases. You see, it's too simple-minded for certain kinds of C programs, in particular, those with what appear to be comments in quoted strings. For that, you'd need something like this, created by Jeffrey Friedl and later modified by Fred Curtis. 
 $/ = undef; $_ = <>; s#/\*[^*]*\*+([^/*][^*]*\*+)*/|("(\\.|[^"\\])*"|'(\\.|[^'\\])*'|.[^/"'\\]*)#defined $2 ? $2 : ""#gse; print;
Reference for this is taken from perlfaq6
Read More

Understanding C++ polymorphism


Understanding of / requirements for polymorphism

To understand polymorphism - as the term is used in Computing Science - it helps to start from a simple test for and definition of it. Consider:
 Type1 x; Type2 y; f(x); f(y);
Here, f() is to perform some operation and is being given values x and y as inputs. To exhibit polymorphism, f() must be able to operate with values of at least two distinct types (e.g. int anddouble), finding and executing type-appropriate code.

C++ mechanisms for polymorphism

Explicit programmer-specified polymorphism

You can write f() such that it can operate on multiple types in any of the following ways:
  • Preprocessing:
    #define f(X) ((X) += 2) // (note: in real code, use a longer uppercase name for a macro!)
  • Overloading:
    void f(int& x) { x += 2; } void f(double& x) { x += 2; }
  • Templates:
    template <typename T> void f(T& x) { x += 2; }
  • Virtual dispatch:
    struct Base { virtual Base& operator+=(int) = 0; }; struct X : Base { X(int n) : n_(n) { } X& operator+=(int n) { n_ += n; return *this; } int n_; }; struct Y : Base { Y(double n) : n_(n) { } Y& operator+=(int n) { n_ += n; return *this; } double n_; }; void f(Base& x) { x += 2; } // run-time polymorphic dispatch

Other related mechanisms

Compiler-provided polymorphism for builtin types, Standard conversions, and casting/coercion are discussed later for completeness as:
  • they're commonly intuitively understood anyway (warranting a "oh, that" reaction),
  • they impact the threshold in requiring, and seamlessness in using, the above mechanisms, and
  • usefully detailed explanation is a fiddly distraction from more important concepts.

Terminology

Further categorisation

Given the polymorphic mechanisms above, we can categorise them in various ways:
  • When is the polymorphic type-specific code selected?
    • Run time means the compiler must generate code for all the types the program might handle while running, and at run-time the correct code is selected (virtual dispatch)
    • Compile time means the choice of type-specific code is made during compilation, and code not used may not even be compiled (every mechanism except virtual dispatch)
  • Which types are supported?
    • Ad-hoc meaning you must provide explicit code to support each type (e.g. overloading); you explicitly add support "for this" (as per ad hoc's meaning) type, some other "this", and maybe "that" too ;-).
    • Parametric meaning you can just try to use the function for various parameter types without specifically doing anything to enable its support for them (e.g. templates, macros). An object with functions/operators that act like the template/macro expects is all that template/macro needs to do its job, with the exact type being irrelevant. The "concepts" cut from C++11 help express and enforce such expectations - let's hope they make it into the next Standard.
      • Parametric polymorphism provides duck typing - a concept attributed to James Whitcomb Riley who apparently said "When I see a bird that walks like a duck and swims like a duck and quacks like a duck, I call that bird a duck.".
        template <typename Duck> void do_ducky_stuff(const Duck& x) { x.walk().swim().quack(); } do_ducky_stuff(Vilified_Cygnet());

"Polymorphic"

Alf Steinbach comments that in the C++ Standard polymorphic only refers to run-time polymorphism using virtual dispatch. General Comp. Sci. meaning is more inclusive, as per C++ creator Bjarne Stroustrup's glossary (http://www2.research.att.com/~bs/glossary.html):
polymorphism - providing a single interface to entities of different types. virtual functions provide dynamic (run-time) polymorphism through an interface provided by a base class. Overloaded functions and templates provide static (compile-time) polymorphism. TC++PL 12.2.6, 13.6.1, D&E 2.9.
This answer - like the question - relates C++ features to the Comp. Sci. terminology.

Discussion

With the C++ Standard using a narrower definition of "polymorphism" than the Comp. Sci. community, to ensure mutual understanding for your audience consider...
  • using unambiguous terminology ("can we make this code reusable for other types?" or "can we use virtual dispatch?" vs "can we make this code polymorphic?"), and/or
  • clearly defining your terminology.
Still, what's crucial to being a great C++ programmer is understanding what polymorphism's really doing for you...
    letting you write "algorithmic" code once and then apply it to many types of data
...and then be very aware of how different polymorphic mechanisms match your actual needs.
Run-time polymorphism suits:
  • input processed by factory methods and spat out as an heterogeneous object collection handled viaBase*s,
  • implementation chosen at runtime based on config files, command line switches, UI settings etc.,
  • implementation varied at runtime, such as for a state machine pattern,
  • pImpl idiom / managing re-compilation coupling.
When there's not a clear driver for run-time polymorphism, compile-time options are often preferable. Consider:
  • the compile-what's-called aspect of templated classes is preferable to fat interfaces failing at runtime
  • SFINAE
  • CRTP
  • optimisations (many including inlining and dead code elimination, loop unrolling, static stack-based arrays vs heap)
  • __FILE__, __LINE__, string literal concatenation and other unique capabilities of macros (which remain evil ;-))

Other mechanisms supporting polymorphism

As promised, for completeness several peripheral topics are covered:
  • compiler-provided overloads
  • conversions
  • casts/coercion
The document concludes with a discussion of how these combine to empower and simplify polymorphic code - especially parametric polymorphism (templates and macros).

Mechanisms for mapping to type-specific operations

> Implicit compiler-provided overloads
Conceptually, the compiler overloads many operators for builtin types. It's not conceptually different from user-specified overloading, but is listed as it's easily overlooked. For example, you can add to ints and doubles using the same notation x += 2 and the compiler produces:
  • type-specific CPU instructions
  • a result of the same type.
Overloading then seemlessly extends to user-defined types:
std::string x; int y = 0; x += 'c'; y += 'c';
Compiler-provided overloads for basic types is common in high-level (3GL+) computer languages, and explicit discussion of polymorphism generally implies something more. (2GLs - assembly languages - often require the programmer to explicitly use different mnemonics for different types.)
> Standard conversions
The C++ Standard's fourth section describes Standard conversions.
The first point summarises nicely (from an old draft - hopefully still substantially correct):
-1- Standard conversions are implicit conversions defined for built-in types. Clause conv enumerates the full set of such conversions. A standard conversion sequence is a sequence of standard conversions in the following order:
  • Zero or one conversion from the following set: lvalue-to-rvalue conversion, array-to-pointer conversion, and function-to-pointer conversion.
  • Zero or one conversion from the following set: integral promotions, floating point promotion, integral conversions, floating point conversions, floating-integral conversions, pointer conversions, pointer to member conversions, and boolean conversions.
  • Zero or one qualification conversion.
[Note: a standard conversion sequence can be empty, i.e., it can consist of no conversions. ] A standard conversion sequence will be applied to an expression if necessary to convert it to a required destination type.
These conversions allow code such as:
double a(double x) { return x + 2; } a(3.14); a(42);
Applying the earlier test:
To be polymorphic, [a()] must be able to operate with values of at least two distinct types (e.g.int and double), finding and executing type-appropriate code.
a() itself runs code specifically for double and is therefore not polymorphic.
But, in the second call to a() the compiler knows to generate type-appropriate code for a "floating point promotion" (Standard §4) to convert 42 to 42.0. That extra code is in the calling function. We'll discuss the significance of this in the conclusion.
> Coercion, casts, implicit constructors
These mechanisms allow user-defined classes to specify behaviours akin to builtin types' Standard conversions. Let's have a look:
int a, b; if (std::cin >> a >> b) f(a, b);
Here, the object std::cin is evaluated in a boolean context, with the help of a conversion operator. This can be conceptually grouped with "integral promotions" et al from the Standard conversions in the topic above.
Implicit constructors effectively do the same thing, but are controlled by the cast-to type:
f(const std::string& x); f("hello"); // invokes `std::string::string(const char*)`

Implications of compiler-provided overloads, conversions and coercion

Consider:
void f() { typedef int Amount; Amount x = 13; x /= 2; std::cout << x * 1.1; }
If we want the amount x to be treated as a real number during the division (i.e. be 6.5 rather than rounded down to 6), we only need change to typedef double Amount.
That's nice, but it wouldn't have been too much work to make the code explicitly "type correct":
void f() void f() { { typedef int Amount; typedef double Amount; Amount x = 13; Amount x = 13.0; x /= 2; x /= 2.0; std::cout << double(x) * 1.1; std::cout << x * 1.1; } }
But, consider that we can transform the first version into a template:
template <typename Amount> void f() { Amount x = 13; x /= 2; std::cout << x * 1.1; }
It's due to those little "convenience features" that it can be so easily instantiated for either int ordouble and work as intended. Without these features, we'd need explicit casts, type traits and/or policy classes, some verbose, error-prone mess like:
template <typename Amount, typename Policy> void f() { Amount x = Policy::thirteen; x /= static_cast<Amount>(2); std::cout << traits<Amount>::to_double(x) * 1.1; }
So, compiler-provided operator overloading for builtin types, Standard conversions, casting / coercion / implicit constructors - they all contribute subtle support for polymorphism. From the definition at the top of this answer, they address "finding and executing type-appropriate code" by mapping:
  • "away" from parameter types
    • from the many data types polymorphic algorithmic code handles
    • to code written for a (potentially lesser) number of (the same or other) types.
  • "to" parametric types from values of constant type
They do not establish polymorphic contexts by themselves, but do help empower/simplify code inside such contexts.
You may feel cheated... it doesn't seem like much. The significance is that in parametric polymorphic contexts (i.e. inside templates or macros), we're trying to support an arbitrarily large range of types but often want to express operations on them in terms of other functions, literals and operations that were designed for a small set of types. It reduces the need to create near-identical functions or data on a per-type basis when the operation/value is logically the same. These features cooperate to add an attitude of "best effort", doing what's intuitively expected by using the limited available functions and data and only stopping with an error when there's real ambiguity.
This helps limit the need for polymorphic code supporting polymorphic code, drawing a tighter net around the use of polymorphism so localised use doesn't force widespread use, and making the benefits of polymorphism available as needed without imposing the costs of having to expose implementation at compile time, have multiple copies of the same logical function in the object code to support the used types, and in doing virtual dispatch as opposed to inlining or at least compile-time resolved calls. As is typical in C++, the programmer is given a lot of freedom to control the boundaries within which polymorphism is used.


Reference is here
Read More
Subscribe to: Comments (Atom)