tag:blogger.com,1999:blog-85259190276807218832024-03-19T12:51:06.901+05:30ccplusplus.comLearn C, C++ ConceptsSaurabh Guptahttp://www.blogger.com/profile/00311810578585599874noreply@blogger.comBlogger1427125tag:blogger.com,1999:blog-8525919027680721883.post-21191131450139276952015-05-08T17:12:00.002+05:302020-12-20T09:54:53.277+05:30We are part of "Gupta Information Systems" Now<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
<i><span style="font-size: large;">Cheers to all,</span></i></div>
<div style="text-align: justify;">
<i><span style="font-size: large;"><br /></span></i></div>
<div style="text-align: justify;">
<span style="font-size: large;"><i>We are structring our website and we are now part of "Gupta Information Systems".</i></span><br />
<span style="font-size: large;"><i><br /></i></span>
<span style="font-size: large;"><i>We will soon come with a new contents for you !!!</i></span><br />
<br />
<br /></div>
<div style="text-align: justify;">
<h3>
<i><u><span style="font-size: large;">Join Us Here</span></u></i></h3>
<div style="text-align: justify;">
<div style="text-align: left;">
<span style="font-size: large;"><i>You can join us and ask any specific questions if you have,</i></span><br />
<br />
<div>
</div>
<meta name="google-site-verification" content="0YFCdvJQdOowtsgsHfXlEiCq-5fgsZ-LoE0jFlHwtZQ" />
<div>
<a href="https://plus.google.com/+GuptaInformationSystems" target="_blank"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg_pmQfMBUCQUIcSNnpMfJ9jWIevVbWu1XVFbQnFhNzdwLBBYxignlok3vGKKKEPMEqKQUqTYW_GnVkwlj-d1B-NmpYezV6UbVznvor6AInoMyHU6zhB3Dy4y8oR1OZGFdbUQ4Vo8MkzF8R/s1600/google-plus.png" /></a> <a href="https://www.youtube.com/c/GuptaInformationSystems" style="clear: left; display: inline !important; margin-bottom: 1em; margin-right: 1em;" target="_blank"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg2Z-a4Fh6j9fuPVk1gsJE3U_4zF6Hwk42_idAe-g777MRFMtbcCvvTk17li8b5dlh2PCJ0mpJtCluqZl_UqBMy0kfXpKjQEQd8bixKX2SBm4Y51ECd8FItsO9rHfcmUed2V1K3Cg0Zg6uZ/s1600/Youtube-icon.png" /></a><a href="https://facebook.com/GuptaInformationSystems" target="_blank"><img alt=" https://www.facebook.com/absolutesaurabh" border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi6kv_RXaPgL9FCNe4FzetKuDmaJUdswDd-6uBIv-6yC5pEoNMbtGlmNAMQ1QUX-IDQ5p37u_Sm_yqGKCsOzqS3x6fNEAedflYaFMjhCKWrUrltIavwlwR13dHZbSy1RIPac1yKJrvkz9tv/s1600/Facebook_logo_%2528square%2529.jpg" /></a> <a href="https://instagram.com/guptainformationsystems/" target="_blank"><img alt=" https://instagram.com/absolutesaurabh/" border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg7YNRm4dGNbdZlw9IwEWJj16GwQSn8AdHJzt3fOr-wMDIOtAS-d0Am7Fx0JMQ1cv2F-qtJhzuES5Fdssn7UVG4gDbMuDiRNB1sdSBUFINXxS2mfpranpjhovNPczTCPao3z_uJFNOEeepG/s1600/Instagram_icon.jpg" /></a> <a href="https://twitter.com/GISSupport" target="_blank"><img alt=" https://twitter.com/absolutesaurabh" border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEisfYTDrvMdOquZuh9WKEj67RPxOrTUcJRncgfhZkRMAYkOWRra2hyphenhyphendS15VMcLibQruZbQj_yWv8JEUmaAU4fhZa9sUw7wZ2JC5jtRRdCuL8lThA3U3CmWbILraBCP5RnnDnjIjEq6Yk3Kn/s1600/Twitter-icon.jpg" /></a></div>
</div>
</div>
</div>
</div>
Gupta Information Systemshttp://www.blogger.com/profile/18414134095351331587noreply@blogger.com11tag:blogger.com,1999:blog-8525919027680721883.post-22727035312698991482015-04-09T15:52:00.003+05:302015-04-09T15:52:16.687+05:30What is a class?<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
The fundamental building block of OO software.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
A <code>class</code> defines a data type, much like a <code>struct</code> would be in C. In a computer science sense, a type consists of both
a set of states <em>and</em> a set of operations which transition between those states. Thus <code>int</code> is a type because it has
both a set of states <em>and</em> it has operations like <code>i + j</code> or <code>i++</code>, etc. In exactly the same way, a <code>class</code> provides a
set of (usually <code>public</code>) operations, and a set of (usually non-<code>public</code>) data bits representing the abstract values
that instances of the type can have.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
You can imagine that <code>int</code> is a <code>class</code> that has member functions called <code>operator++</code>, etc. (<code>int</code> isn’t really a
<code>class</code>, but the basic analogy is this: a <code>class</code> is a type, much like <code>int</code> is a type.)</div>
<div style="text-align: justify;">
<br /></div>
<br />
<div style="text-align: justify;">
Note: a C programmer can think of a <code>class</code> as a C <code>struct</code> whose members default to <code>private</code>. But if that’s all you
think of a <code>class</code>, then you probably need to experience a personal paradigm shift.</div>
</div>
Gupta Information Systemshttp://www.blogger.com/profile/18414134095351331587noreply@blogger.com2tag:blogger.com,1999:blog-8525919027680721883.post-4111491743665937712015-04-09T15:51:00.005+05:302015-04-09T15:51:48.783+05:30What is an object?<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
A region of storage with associated semantics.</div>
<div style="text-align: justify;">
<br /></div>
<br />
<div style="text-align: justify;">
After the declaration <code>int i;</code> we say that “<code>i</code> is an object of type <code>int</code>.” In OO/C++, “object” usually means “an
instance of a class.” Thus a class defines the behavior of possibly many objects (instances).</div>
</div>
Gupta Information Systemshttp://www.blogger.com/profile/18414134095351331587noreply@blogger.com0tag:blogger.com,1999:blog-8525919027680721883.post-52282179886376377302015-04-09T15:51:00.002+05:302015-04-09T15:51:25.651+05:30When is an interface “good”?<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
When it provides a <em>simplified view</em> of a chunk of software, and it is expressed in the <em>vocabulary of a user</em> (where a
“chunk” is normally a class or a tight group of classes, and a “user” is another developer rather
than the ultimate customer).</div>
<br />
<ul>
<li style="text-align: justify;">The “simplified view” means unnecessary details are intentionally hidden. This reduces the user’s defect-rate.</li>
<li style="text-align: justify;">The “vocabulary of users” means users don’t need to learn a new set of words and concepts. This reduces the user’s
learning curve.</li>
</ul>
</div>
Gupta Information Systemshttp://www.blogger.com/profile/18414134095351331587noreply@blogger.com0tag:blogger.com,1999:blog-8525919027680721883.post-69752617118865932062015-04-09T15:50:00.002+05:302015-04-09T15:50:35.179+05:30What is encapsulation? <div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
Preventing unauthorized access to some piece of information or functionality.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
The key money-saving insight is to separate the volatile part of some chunk of software from the stable part.
Encapsulation puts a firewall around the chunk, which prevents other chunks from accessing the volatile parts; other
chunks can only access the stable parts. This prevents the other chunks from breaking if (when!) the volatile parts are
changed. In context of OO software, a “chunk” is normally a class or a tight group of classes.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
The “volatile parts” are the implementation details. If the chunk is a single class, the volatile part is normally
encapsulated using the <code>private</code> and/or <code>protected</code> keywords. If the chunk is a tight group of
classes, encapsulation can be used to deny access to entire classes in that group.
Inheritance can also be used as a form of encapsulation.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
The “stable parts” are the interfaces. A good interface provides a simplified view in the vocabulary of a
user, and is designed from the outside-in (here a “user” means another
developer, not the end-user who buys the completed application). If the chunk is a single class, the interface is
simply the class’s <code>public</code> member functions and <code>friend</code> functions. If the chunk is a tight group of
classes, the interface can include several of the classes in the chunk.</div>
<div style="text-align: justify;">
<br /></div>
<br />
<div style="text-align: justify;">
Designing a clean interface and separating that interface from its implementation merely
<em>allows</em> users to use the interface. But encapsulating (putting “in a capsule”) the implementation <em>forces</em> users to use
the interface.</div>
</div>
Gupta Information Systemshttp://www.blogger.com/profile/18414134095351331587noreply@blogger.com1tag:blogger.com,1999:blog-8525919027680721883.post-39167572896028492312015-04-09T15:49:00.001+05:302015-04-09T15:49:38.011+05:30How does C++ help with the tradeoff of safety vs. usability?<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
In C, encapsulation was accomplished by making things <code>static</code> in a compilation unit or module. This
prevented another module from accessing the <code>static</code> stuff. (By the way, <code>static</code> data at file-scope is now deprecated
in C++: don’t do that.)</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Unfortunately this approach doesn’t support multiple instances of the data, since there is no direct support for making
multiple instances of a module’s <code>static</code> data. If multiple instances were needed in C, programmers typically used a
<code>struct</code>. But unfortunately C <code>struct</code>s don’t support encapsulation. This exacerbates the tradeoff
between safety (information hiding) and usability (multiple instances).</div>
<div style="text-align: justify;">
In C++, you can have both multiple instances and encapsulation via a class. The <code>public</code> part of a class contains the
class’s interface, which normally consists of the class’s <code>public</code> member functions and its <code>friend</code>
functions. The <code>private</code> and/or <code>protected</code> parts of a class contain the class’s implementation, which
is typically where the data lives.</div>
<div style="text-align: justify;">
<br /></div>
<br />
<div style="text-align: justify;">
The end result is like an “encapsulated <code>struct</code>.” This reduces the tradeoff between safety (information hiding) and
usability (multiple instances).</div>
</div>
Gupta Information Systemshttp://www.blogger.com/profile/18414134095351331587noreply@blogger.com0tag:blogger.com,1999:blog-8525919027680721883.post-89765651548309407532015-04-09T15:48:00.004+05:302015-04-09T15:48:56.303+05:30How can I prevent other programmers from violating encapsulation by seeing the private parts of my class? <div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
Not worth the effort — encapsulation is for code, not people.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
It doesn’t violate encapsulation for a <em>programmer</em> to see the <code>private</code> and/or <code>protected</code> parts of
your class, so long as they don’t write code that somehow depends on what they saw. In other words, encapsulation
doesn’t prevent <em>people</em> from knowing about the inside of a class; it prevents the <em>code</em> they write from becoming
dependent on the insides of the class. Your company doesn’t have to pay a “maintenance cost” to maintain the gray matter
between your ears; but it does have to pay a maintenance cost to maintain the code that comes out of your finger tips.
What you know as a person doesn’t increase maintenance cost, provided the code you write depends on the interface rather
than the implementation.</div>
<br />
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Besides, this is rarely if ever a problem. I don’t know any programmers who have intentionally tried to access the
<code>private</code> parts of a class. “My recommendation in such cases would be to change the programmer, not the code” [James
Kanze; used with permission].</div>
</div>
Gupta Information Systemshttp://www.blogger.com/profile/18414134095351331587noreply@blogger.com1tag:blogger.com,1999:blog-8525919027680721883.post-49115904766094013722015-04-09T15:48:00.000+05:302015-04-09T15:48:17.296+05:30Can a method directly access the non-public members of another instance of its class?<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
Yes.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
The name <code>this</code> is not special. Access is granted or denied based on the <em>class</em> of the reference/pointer/object, not
based on the <em>name</em> of the reference/pointer/object. (See below for the fine print.)</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
The fact that C++ allows a class’ methods and friends to access the non-<code>public</code> parts of <em>all</em> its objects, not just
the <code>this</code> object, seems at first to weaken encapsulation. However the opposite is true: this rule preserves
encapsulation. Here’s why.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Without this rule, most non-<code>public</code> members would need a <code>public</code> <em>get</em> method, because many classes have at least one
method or friend that takes an explicit argument (i.e., an argument not called <code>this</code>) of its own class.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Huh? (you ask). Let’s kill the mumbo jumbo and work out an example:</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Consider assignment operator <code>Foo::operator=(const Foo& x)</code>. This assignment operator will probably change the data
members in the left-hand argument, <code>*this</code>, based on the data members in the right-hand argument, <code>x</code>. Without the
C++ rule being discussed here, the only way for that assignment operator to access the non-<code>public</code> members of <code>x</code>
would be for class <code>Foo</code> to provide a <code>public</code> <em>get</em> method for every non-<code>public</code> datum. That would suck bigtime.
(NB: “suck bigtime” is a precise, sophisticated, technical term; and I am writing this on April 1.)</div>
<div style="text-align: justify;">
The assignment operator isn’t the only one that would weaken encapsulation were it not for this rule. Here is a
partial(!) list of others:</div>
<ul>
<li style="text-align: justify;">Copy constructor.</li>
<li style="text-align: justify;">Comparison operators: <code>==</code>, <code>!=</code>, <code><=</code>, <code><</code>, <code>>=</code>, <code>></code>.</li>
<li style="text-align: justify;">Binary arithmetic operators: <code>x+y</code>, <code>x-y</code>, <code>x*y</code>, <code>x/y</code>, <code>x%y</code>.</li>
<li style="text-align: justify;">Binary bitwise operators: <code>x^y</code>, <code>x&y</code>, <code>x|y</code>.</li>
<li style="text-align: justify;">Static methods that accepts an instance of the class as a parameter.</li>
<li style="text-align: justify;">Static methods that creates/manipulates an instance of the class.</li>
<li style="text-align: justify;">etc.</li>
</ul>
<div style="text-align: justify;">
Conclusion: encapsulation would be shredded without this beneficial rule: most non-<code>public</code> members of most classes
would end up having a <code>public</code> <em>get</em> method.</div>
<div style="text-align: justify;">
<br /></div>
<br />
<div style="text-align: justify;">
<em>The Fine Print:</em> There is another rule that is related to the above: methods and friends of a derived class can
access the <code>protected</code> base class members of any of its own objects (any objects of its class or any derived class of
its class), but not others. Since that is hopelessly opaque, here’s an example: suppose classes <code>D1</code> and <code>D2</code> inherit
directly from class <code>B</code>, and base class <code>B</code> has <code>protected</code> member <code>x</code>. The compiler will let <code>D1</code>’s members and friends
directly access the <code>x</code> member of any object it knows to be at least a <code>D1</code>, such as via a <code>D1*</code> pointer, a <code>D1&</code>
reference, a <code>D1</code> object, etc. However the compiler will give a compile-time error if a <code>D1</code> member or friend tries to
directly access the <code>x</code> member of anything it does not know is at least a <code>D1</code>, such as via a <code>B*</code> pointer, a <code>B&</code>
reference, a <code>B</code> object, a <code>D2*</code> pointer, a <code>D2&</code> reference, a <code>D2</code> object, etc. By way of (imperfect!!) analogy, you
are allowed to pick your own pockets, but you are not allowed to pick your father’s pockets nor your brother’s pockets.</div>
</div>
Gupta Information Systemshttp://www.blogger.com/profile/18414134095351331587noreply@blogger.com1tag:blogger.com,1999:blog-8525919027680721883.post-46127455475446882112015-04-09T15:46:00.005+05:302015-04-09T15:46:36.957+05:30Is Encapsulation a Security device? <div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
No.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Encapsulation <code>!=</code> security.</div>
<div style="text-align: justify;">
<br /></div>
<br />
<div style="text-align: justify;">
Encapsulation prevents mistakes, not espionage.</div>
</div>
Gupta Information Systemshttp://www.blogger.com/profile/18414134095351331587noreply@blogger.com4tag:blogger.com,1999:blog-8525919027680721883.post-37350410699018886492015-04-09T15:46:00.002+05:302015-04-09T15:46:10.460+05:30What’s the difference between the keywords struct and class?<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
The members and base classes of a <code>struct</code> are <code>public</code> by default, while in <code>class</code>, they default to <code>private</code>. Note:
you should make your base classes <em>explicitly</em> <code>public</code>, <code>private</code>, or <code>protected</code>, rather than relying on the defaults.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<code>struct</code> and <code>class</code> are otherwise functionally equivalent.</div>
<div style="text-align: justify;">
<br /></div>
<br />
<div style="text-align: justify;">
Enough of that squeaky clean techno talk. Emotionally, most developers make a strong distinction between a <code>class</code> and a
<code>struct</code>. A <code>struct</code> simply <em>feels</em> like an open pile of bits with very little in the way of encapsulation or
functionality. A <code>class</code> <em>feels</em> like a living and responsible member of society with intelligent services, a strong
encapsulation barrier, and a well defined interface. Since that’s the connotation most people already have, you should
probably use the <code>struct</code> keyword if you have a class that has very few methods and has <code>public</code> data (such things <em>do</em>
exist in well designed systems!), but otherwise you should probably use the <code>class</code> keyword.</div>
</div>
Gupta Information Systemshttp://www.blogger.com/profile/18414134095351331587noreply@blogger.com1tag:blogger.com,1999:blog-8525919027680721883.post-12647421887269522532015-04-09T15:45:00.003+05:302015-04-09T15:45:35.957+05:30How do I define an in-class constant?<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
If you want a constant that you can use in a compile time constant expression, say as an array bound, use <code>constexpr</code> if your compiler supports that C++11 feature, otherwise you have two other choices:</div>
<textarea class="c" name="code">class X {
constexpr int c1 = 42; // preferred
static const int c2 = 7;
enum { c3 = 19 };
array<char,c1> v1;
array<char,c2> v2;
array<char,c3> v3;
// ...
};
</textarea>
<br />
<div style="text-align: justify;">
You have more flexibility if the constant isn’t needed for use in a compile time constant expression:</div>
<textarea class="c" name="code"> class Z {
static char* p; // initialize in definition
const int i; // initialize in constructor
public:
Z(int ii) :i(ii) { }
};
char* Z::p = "hello, there";
</textarea>
<br />
<div style="text-align: justify;">
You can take the address of a static member if (and only if) it has an out-of-class definition:</div>
<textarea class="c" name="code"> class AE {
// ...
public:
static const int c6 = 7;
static const int c7 = 31;
};
const int AE::c7; // definition
int f()
{
const int* p1 = &AE::c6; // error: c6 not an lvalue
const int* p2 = &AE::c7; // ok
// ...
}
</textarea>
</div>
Gupta Information Systemshttp://www.blogger.com/profile/18414134095351331587noreply@blogger.com0tag:blogger.com,1999:blog-8525919027680721883.post-86296806131573876332015-04-09T15:43:00.001+05:302015-04-09T15:43:22.929+05:30Why do I have to put the data in my class declarations?<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
You don’t. If you don’t want data in an interface, don’t put it in
the class that defines the interface. Put it in derived classes instead.
See, Why do my compiles take so long?.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Sometimes, you do want to have representation data in a class. Consider class <code>complex</code>:</div>
<textarea class="c" name="code">
template<class Scalar> class complex {
public:
complex() : re(0), im(0) { }
complex(Scalar r) : re(r), im(0) { }
complex(Scalar r, Scalar i) : re(r), im(i) { }
// ...
complex& operator+=(const complex& a)
{ re+=a.re; im+=a.im; return *this; }
// ...
private:
Scalar re, im;
};
</textarea>
<br />
<div style="text-align: justify;">
This type is designed to be used much as a built-in type and the
representation is needed in the declaration to make it possible to
create genuinely local objects (i.e. objects that are allocated on the
stack and not on a heap) and to ensure proper inlining of simple
operations. Genuinely local objects and inlining is necessary to get the
performance of complex close to what is provided in languages with a
built-in complex type.</div>
</div>Gupta Information Systemshttp://www.blogger.com/profile/18414134095351331587noreply@blogger.com1tag:blogger.com,1999:blog-8525919027680721883.post-87658310451840939082015-04-09T15:42:00.001+05:302015-04-09T15:42:12.329+05:30How are C++ objects laid out in memory?<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
Like C, C++ doesn’t define layouts, just semantic constraints that
must be met. Therefore different implementations do things differently.
One good explanation is in a book that is otherwise outdated and doesn’t
describe any current C++ implementation: <a href="http://stroustrup.com/arm.html">The Annotated C++ Reference Manual</a> (usually called the ARM). It has diagrams of key layout examples. There is a very brief explanation in Chapter 2 of <a href="http://stroustrup.com/3rd.html">TC++PL3</a>.</div>
<div style="text-align: justify;">
Basically, C++ constructs objects simply by concatenating sub objects. Thus</div>
<textarea class="c" name="code">struct A { int a,b; };
</textarea>
<br />
<div style="text-align: justify;">
is represented by two <code>int</code>s next to each other, and</div>
<textarea class="c" name="code"> struct B : A { int c; };
</textarea>
<br />
<div style="text-align: justify;">
is represented by an <code>A</code> followed by an <code>int</code>; that is, by three <code>int</code>s next to each other.</div>
<br />
<div style="text-align: justify;">
Virtual functions are typically implemented by adding a pointer (the
“vptr”) to each object of a class with virtual functions. This pointer
points to the appropriate table of functions (the “vtbl”). Each class
has its own vtbl shared by all objects of that class.</div>
</div>
Gupta Information Systemshttp://www.blogger.com/profile/18414134095351331587noreply@blogger.com1tag:blogger.com,1999:blog-8525919027680721883.post-19809847353578587342015-04-09T15:40:00.000+05:302015-04-09T15:40:10.092+05:30Why is the size of an empty class not zero? <div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
To ensure that the addresses of two different objects will be different. For the same reason, <code>new</code> always returns pointers to distinct objects. Consider:</div>
<textarea class="c" name="code">
class Empty { };
void f()
{
Empty a, b;
if (&a == &b) cout << "impossible: report error to compiler supplier";
Empty* p1 = new Empty;
Empty* p2 = new Empty;
if (p1 == p2) cout << "impossible: report error to compiler supplier";
}
</textarea>
<div style="text-align: justify;">
There is an interesting rule that says that an empty base class need not be represented by a separate byte:</div>
<textarea class="c" name="code">
struct X : Empty {
int a;
// ...
};
void f(X* p)
{
void* p1 = p;
void* p2 = &p->a;
if (p1 == p2) cout << "nice: good optimizer";
}
</textarea>
<div style="text-align: justify;">
This optimization is safe and can be most useful. It allows a
programmer to use empty classes to represent very simple concepts
without overhead. Some current compilers provide this “empty base class
optimization”.</div>
<br />
<div style="text-align: justify;">
Moreover, “empty base class optimization” is no longer an optional
optimization but a mandatory requirement on class layout as of C++11. Go
beat up on your compiler vendor if it does not implement it properly.</div>
</div>Gupta Information Systemshttp://www.blogger.com/profile/18414134095351331587noreply@blogger.com0tag:blogger.com,1999:blog-8525919027680721883.post-9392687922756107402015-04-09T15:27:00.000+05:302015-04-09T15:27:54.625+05:30content coming soon<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="background-color: white; clear: both; color: #444444; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13px; line-height: 18.2000007629395px; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhk6hhg-ZPuHRr9hEtsL7-b24LoqC8xl_ZoCSJPojDeVTpeGfpKkGXOhGmChE0kS3KTcXHa5KoeCAO3Q1U5cymcLWMv6DJT0_QuA8rI-zoakY7LBZOoLv31hRMxFpjF-oBg44tapsWxxxrk/s1600/Coming-Soon.png" imageanchor="1" style="color: #4d469c; margin-left: 1em; margin-right: 1em; text-decoration: none;"><img border="0" height="85" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhk6hhg-ZPuHRr9hEtsL7-b24LoqC8xl_ZoCSJPojDeVTpeGfpKkGXOhGmChE0kS3KTcXHa5KoeCAO3Q1U5cymcLWMv6DJT0_QuA8rI-zoakY7LBZOoLv31hRMxFpjF-oBg44tapsWxxxrk/s1600/Coming-Soon.png" style="-webkit-box-shadow: rgba(0, 0, 0, 0.2) 0px 0px 0px; background: transparent; border-radius: 0px; border: 1px solid transparent; box-shadow: rgba(0, 0, 0, 0.2) 0px 0px 0px; padding: 8px; position: relative;" width="200" /></a></div>
<span style="background-color: white; color: blue; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13px; line-height: 18.2000007629395px;"><br /></span><span style="background-color: white; color: #444444; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13px; line-height: 18.2000007629395px;"></span>
<div style="background-color: white; color: #444444; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13px; line-height: 18.2000007629395px; text-align: center;">
<span style="font-size: medium;"><i><span style="color: blue;">This means that the content will be coming very soon. This may take upto 7 days of time at max.</span></i></span></div>
</div>
Gupta Information Systemshttp://www.blogger.com/profile/18414134095351331587noreply@blogger.com0tag:blogger.com,1999:blog-8525919027680721883.post-77805113507159417332015-04-09T15:24:00.005+05:302015-04-09T15:24:52.107+05:30What is C++? <div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
C++ is a general-purpose programming language with a bias towards systems programming that</div>
<ul>
<li style="text-align: justify;">is a better C</li>
<li style="text-align: justify;">supports data abstraction (e.g., classes)</li>
<li style="text-align: justify;">supports object-oriented programming (e.g., inheritance)</li>
<li style="text-align: justify;">supports generic programming (e.g., reusable generic containers and algorithms)</li>
<li style="text-align: justify;">supports functional programming (e.g., template metaprogramming, lambda functions, <code>constexpr</code>)</li>
</ul>
<div style="text-align: justify;">
It is defined by an ISO standard, offers stability over decades, and has a large and lively user community. See also <a href="http://stroustrup.com/4th.html">The C++ Programming Language</a> and <a href="http://stroustrup.com/hopl-almost-final.pdf">Evolving a language in and for the real world: C++ 1991-2006</a>.</div>
<br />
<div style="text-align: justify;">
See also <a href="http://isocpp.org/wiki/faq/big-picture#when-invented" title="FAQ: When was C++ invented?">when</a> and <a href="http://isocpp.org/wiki/faq/big-picture#why-invented" title="FAQ: Why was C++ invented?">why</a> C++ was invented.</div>
</div>
Gupta Information Systemshttp://www.blogger.com/profile/18414134095351331587noreply@blogger.com0tag:blogger.com,1999:blog-8525919027680721883.post-57068227653444283882015-04-09T15:24:00.001+05:302015-04-09T15:24:04.012+05:30Is C++ a practical language?<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
Yes.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
C++ is a practical tool. It’s not perfect, but it’s useful.</div>
<div style="text-align: justify;">
<br /></div>
<br />
<div style="text-align: justify;">
In the world of industrial software, C++ is viewed as a solid, mature, mainstream tool. It has widespread industry
support which makes it “good” from an overall business perspective.</div>
</div>
Gupta Information Systemshttp://www.blogger.com/profile/18414134095351331587noreply@blogger.com0tag:blogger.com,1999:blog-8525919027680721883.post-90019258072521306612015-04-09T15:23:00.003+05:302015-04-09T15:23:36.353+05:30Is C++ a perfect language?<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
Nope.</div>
<div style="text-align: justify;">
<br /></div>
<br />
<div style="text-align: justify;">
C++ wasn’t designed to demonstrate what a perfect language looks like. It was designed to be a practical tool for
solving real world problems. It has a few warts, as do all practical programming tools, but the only place where it’s
appropriate to keep fiddling with something until it’s perfect is in a pure academic setting. That wasn’t C++’s goal.</div>
</div>
Gupta Information Systemshttp://www.blogger.com/profile/18414134095351331587noreply@blogger.com0tag:blogger.com,1999:blog-8525919027680721883.post-46450305345052343912015-04-09T15:23:00.000+05:302015-04-09T15:23:00.362+05:30What’s so great about classes?<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
Classes are there to help you organize your code and to reason about
your programs. You could roughly equivalently say that classes are there
to help you avoid making mistakes and to help you find bugs after you
do make a mistake. In this way, classes significantly help maintenance.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
A class is the representation of an idea, a concept, in the code. An
object of a class represents a particular example of the idea in the
code. Without classes, a reader of the code would have to guess about
the relationships among data items and functions – classes make such
relationships explicit and “understood” by compilers. With classes, more
of the high-level structure of your program is reflected in the code,
not just in the comments.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
A well-designed class presents a clean and simple interface to its
users, hiding its representation and saving its users from having to
know about that representation. If the representation shouldn’t be
hidden – say, because users should be able to change any data member any
way they like – you can think of that class as “just a plain old data
structure”; for example:</div>
<textarea class="c" name="code">struct Pair {
Pair(const string& n, const string& v) : name(n), value(v) { }
string name, value;
};
</textarea><br />
<div style="text-align: justify;">
Note that even data structures can benefit from auxiliary functions,
such as constructors.
When designing a class, it is often useful to consider what’s true for
every object of the class and at all times. Such a property is called an
invariant. For example, the invariant of a <code>vector</code> could be
that (a) its representation consists of a pointer to a number of
elements and (b) that number of elements is stored in an integer. It is
the job of every constructor to establish the class invariant, so that
every member function can rely on it. Every member function must leave
the invariant valid upon exit. This kind of thinking is particularly
useful for classes that manage resources such as locks, sockets, and
files. For example, a file handle class will have the invariant that it
holds a pointer to an open file. The file handle constructor opens the
file. Destructors free resources acquired by constructors. For example,
the destructor for a file handle closes the file opened by the
constructor:</div>
<textarea class="c" name="code">class File_handle {
public:
File_handle(const char* n, const char* rw)
{ f = fopen(n,rw); if (f==nullptr) throw Open_failure(n); }
~File_handle() { fclose(f); } // destructor
// ...
private:
FILE* f;
};
</textarea><br />
<div style="text-align: justify;">
If you haven’t programmed with classes, you will find parts of this
explanation obscure and you’ll underestimate the usefulness of classes.
Look for examples. Like all good textbooks, <a href="http://www.stroustrup.com/4th.html">TC++PL</a> has lots of examples; for example, see <a href="http://www.stroustrup.com/tour2.pdf">A Tour of the Standard Library</a>.
Most modern C++ libraries consist (among other things) of classes and a
library tutorial is one of the best places to look for examples of
useful classes.</div>
</div>
Gupta Information Systemshttp://www.blogger.com/profile/18414134095351331587noreply@blogger.com1tag:blogger.com,1999:blog-8525919027680721883.post-35433996219737273982015-04-09T15:19:00.003+05:302015-04-09T15:19:49.906+05:30What’s the big deal with OO?<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
Object-oriented techniques using classes and virtual functions are an
important way to develop large, complex software applications and
systems. So are generic programming techniques using templates.
Both are important ways to express polymorphism – at run time and at
compile time, respectively. And they work great together in C++.</div>
<div style="text-align: justify;">
There are lots of definitions of “object oriented”, “object-oriented
programming”, and “object-oriented programming languages”. For a longish
explanation of what Stroustrup thinks of as “object oriented”, read <a href="http://www.stroustrup.com/oopsla.pdf">Why C++ isn’t just an object-oriented programming language</a>.
That said, object-oriented programming is a style of programming
originating with Simula (about 40 years ago!) relying on encapsulation,
inheritance, and polymorphism. In the context of C++ (and of many other
languages with their roots in Simula), it means programming using class
hierarchies and virtual functions to allow manipulation of objects of a
variety of types through well-defined interfaces and to allow a program
to be extended incrementally through derivation.</div>
<div style="text-align: justify;">
See whats so great about classes
for an idea about what’s great about “plain classes”. The point about
arranging classes into a class hierarchy is to express hierarchical
relationships among classes and to use those relationships to simplify
code.</div>
<div style="text-align: justify;">
To really understand OOP, look for some examples. For example, you
might have two (or more) device drivers with a common interface:</div>
<textarea class="c" name="code">class Driver { // common driver interface
public:
virtual int read(char* p, int n) = 0; // read max n characters from device to p
// return the number of characters read
virtual bool reset() = 0; // reset device
virtual Status check() = 0; // read status
};
</textarea>
<br />
<div style="text-align: justify;">
This <code>Driver</code> is simply an interface. It is defined with no data members and a set of pure virtual functions. A <code>Driver</code> can be used through this interface and many different kinds of drivers can implement this interface:</div>
<textarea class="c" name="code">class Driver1 : public Driver { // a driver
public:
Driver1(Register); // constructor
int read(char*, int n) override;
bool reset() override;
Status check() override;
private:
// implementation details, including representation
};
class Driver2 : public Driver { // another driver
public:
Driver2(Register);
int read(char*, int n) override;
bool reset() override;
Status check() override;
private:
// implementation details, including representation
};
</textarea>
<br />
<div style="text-align: justify;">
Note that these drivers hold data (state) and objects of them can be created. They implement the functions defined in <code>Driver</code>. We can imagine a driver being used like this:</div>
<textarea class="c" name="code">void f(Driver& d) // use driver
{
Status old_status = d.check();
// ...
d.reset();
char buf[512];
int x = d.read(buf,512);
// ...
}
</textarea>
<br />
<div style="text-align: justify;">
The key point here is that <code>f()</code> doesn’t need to know which kind of driver it uses; all it needs to know is that it is passed a <code>Driver</code>; that is, an interface to many different kinds of drivers. We could invoke <code>f()</code> like this:</div>
<textarea class="c" name="code">void g()
{
Driver1 d1(Register(0xf00)); // create a Driver1 for device
// with device register at address 0xf00
Driver2 d2(Register(0xa00)); // create a Driver2 for device
// with device register at address 0xa00
// ...
int dev;
cin >> dev;
if (dev==1)
f(d1); // use d1
else
f(d2); // use d2
// ...
}
</textarea>
<br />
<div style="text-align: justify;">
Note that when <code>f()</code> uses a <code>Driver</code> the right kind of operations are implicitly chosen at run time. For example, when <code>f()</code> is passed <code>d1</code>, <code>d.read()</code> uses <code>Driver1::read()</code>, whereas when <code>f()</code> is passed <code>d2</code>, <code>d.read()</code> uses <code>Driver2::read()</code>. This is sometimes called run-time dispatch or dynamic dispatch. In this case there is no way that <code>f()</code> could know the kind of device it is called with because we choose it based on an input.</div>
<div style="text-align: justify;">
Please note that object-oriented programming is not a panacea. “OOP”
does not simply mean “good” – if there are no inherent hierarchical
relationships among the fundamental concepts in your problem then no
amount of hierarchy and virtual functions will improve your code. The
strength of OOP is that there are many problems that can be usefully
expressed using class hierarchies – the main weakness of OOP is that too
many people try to force too many problems into a hierarchical mold.
Not every program should be object-oriented. As alternatives, consider plain classes, generic programming, and free-standing functions (as in math, C, and Fortran).</div>
<div style="text-align: justify;">
If you’re still wondering “why OO?”, consider also business reasons:</div>
<div style="text-align: justify;">
The software industry is succeeding at automating many of life’s functions that used to be manual. In addition, software is
improving the flexibility of devices that were previously automated, for example, transforming the internal
implementation of many previously existing devices from mechanical to software (clocks, automobile ignition systems,
etc.) or from being controlled by electrical circuitry to software (TVs, kitchen appliances, etc.). And, of course,
software is integrated into every aspect of our daily business lives — originally software was limited to Accounting
and Finance, but it is now embedded in Operations, Marketing, Sales, and Management — software is nearly everywhere.</div>
<div style="text-align: justify;">
This incredible success has constantly stressed the ability of the software development organizations to keep up. As an
industry, software development has continuously failed to meet the demands for large, complex software systems. Yes,
this failure is actually due to the success of software’s ability to bring perceived value — it is actually caused
because demand is greater than our ability to satisfy that demand. And while it is possible for us software people to
sit around and pat ourselves on the back for that demand, innovators and thought leaders in this and every other
discipline are marked by one undeniable characteristic: they/we are not satisfied. As an industry, we must do better. A
<em>lot</em> better. Uber better.</div>
<div style="text-align: justify;">
Our past successes have propelled users to ask for more. We created a market hunger that Structured Analysis, Design and
Programming techniques have not been able to satisfy. This required us to create a better paradigm. Several, in fact.</div>
<div style="text-align: justify;">
C++ supports OO programming. C++ can also be used as a traditional, imperative programming language (“as a better
C”) or using the generic programming approach. Naturally each of these approaches has its pros and
cons; don’t expect the benefits of one technique while using another. (Most common case of misunderstanding: don’t
expect to get the benefits of object-oriented programming if you’re using C++ as a better C.)</div>
<div style="text-align: justify;">
C++ also supports the generic programming approach. And most recently C++ is starting to support
(as opposed to merely allow) the functional programming approach. The best programmers are able to decide which approach
fits best in which situation, rather than trying to shove a single approach (“my favorite approach”) at every problem
everywhere in every industry irrespective of the business context or the sponsor’s goals.</div>
<br />
<div style="text-align: justify;">
Most importantly, sometimes the best solution is achieved by using a
combination of features from Object-Oriented, Generic and Functional
programming styles, whereas trying to restrict oneself to one particular
approach may lead to a suboptimal solution.</div>
</div>
Gupta Information Systemshttp://www.blogger.com/profile/18414134095351331587noreply@blogger.com0tag:blogger.com,1999:blog-8525919027680721883.post-26239407164428786822015-04-09T15:16:00.001+05:302015-04-09T15:16:16.170+05:30What’s the big deal with generic programming? <div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
Generic programming techniques using templates are an important way
to develop large, complex software applications and systems. So are object oriented techniques.
Both are important ways to express polymorphism – at compile time and
at run time, respectively. And they work great together in C++.</div>
<div style="text-align: justify;">
C++ supports generic programming. Generic programming is a way of developing software that maximizes code reuse in a
way that does not sacrifice performance. (The “performance” part isn’t strictly necessary, but it is highly desirable.)</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Generic programming is programming based on parameterization: You can parameterize a type with another (such as a <code>vector</code>
with its element types) and an algorithm with another (such as a sort
function with a comparison function). The aim of generic programming is
to generalize a useful algorithm or data structure to its most general
and useful form. For example, a <code>vector</code> of integers is fine and so is a function that finds the largest value in a <code>vector</code> of integers. However, a better generic find function will be able to find an element in a <code>vector</code> of any type or better still in any sequence of elements described with a pair of iterators:</div>
<textarea class="c" name="code">
auto p = find(begin(vs), end(vs), "Grail"s); // vector<string> vs; p is vector<string>::iterator
auto q = find(begin(vi), end(vi), 42); // vector<int> vi; q is vector<int>::iterator
auto r = find(begin(ld), end(ld), 1.2); // list<double> ld; r is list<double>::iterator
auto s = find(begin(ar), end(ar), 10); // int ar[10]; s is int *
</textarea>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
These examples are from the STL (the containers and algorithms part
of the ISO C++ standard library); for a brief introduction, see <a href="http://www.stroustrup.com/tour2.pdf">A Tour of the Standard Library</a> from <a href="http://www.stroustrup.com/3rd.html">TC++PL</a>.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Generic programming is in some ways more flexible than
object-oriented programming. In particular, it does not depend on
hierarchies. For example, there is no hierarchical relationship between
an <code>int</code> and a <code>string</code>. Generic programming is
generally more structured than OOP; in fact, a common term used to
describe generic programming is “parametric polymorphism”, with “ad hoc
polymorphism” being the corresponding term for object-oriented
programming. In the context of C++, generic programming resolves all
names at compile time; it does not involve dynamic (run-time) dispatch.
This has led generic programming to become dominant in areas where
run-time performance is important.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Please note that generic programming is not a panacea. There are many
parts of a program that need no parameterization and many examples
where run-time dispatch (OOP) is more approriate.</div>
<div style="text-align: justify;">
Generic components are pretty easy to use, at least if they’re designed well, and they tend to hide a lot of complexity.
The other interesting feature is that they tend to make your code faster, particularly if you use them more. This
creates a pleasant non-tradeoff: when you use the components to do the nasty work for you, your code gets smaller and
simpler, you have less chance of introducing errors, and your code will often run faster.</div>
<div style="text-align: justify;">
<br /></div>
<br />
<div style="text-align: justify;">
Most developers are not cut out to create these generic components,
but most can use them. Fortunately generic components are, um, generic,
so your organization does not often need to create a lot of them. There
are many off-the-shelf libraries of generic components. STL is one such library. <a href="http://www.boost.org/">Boost</a>
has a bunch more. </div>
</div>
Gupta Information Systemshttp://www.blogger.com/profile/18414134095351331587noreply@blogger.com0tag:blogger.com,1999:blog-8525919027680721883.post-54707774667489922562015-04-09T15:14:00.000+05:302015-04-09T15:14:22.172+05:30What is multiparadigm programming? <div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
In short: The same as just “programming,” using different features (notably OO and generic styles) in combination as needed.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Back when having OO and generic programming in the same language was
still new, “multiparadigm programming” was originally a fancy way of
saying “programming using more than one programming style, each to its
best effect.” For example, using object-oriented programming when
run-time resolution between different object types is required and
generic programming when static type safety and run-time performance is
at a premium. Naturally, the main strength of multiparadigm programming
is in programs where more than one paradigm (programming style) is used,
so that it would be hard to get the same effect by composing a system
out of parts written in languages supporting different paradigms. The
most compelling cases for multiparadigm programming are found where
techniques from different paradigms are used in close collaboration to
write code that is more elegant and more maintainable than would be
possible within a single paradigm. A simple example is the traversal of a
statically typed container of objects of a polymorphic type:</div>
<textarea class="c" name="code">void draw_all(vector<Shape*>& vs) // draw each element of a standard vector
{
for_each(vs.begin(),vs.end(),[](Shape* p){ p->draw(); });
}
</textarea>
Here, <code>Shape</code> will be an abstract base class defining the
interface to a hierarchy of geometric shapes. This example easily
generalizes to any standard library container:<br />
<textarea class="c" name="code">template<class C>
void draw_all(C& cs) // draw each element of a standard container
{
for_each(cs.begin(),cs.end(),[](Shape* p){ p->draw(); });
}
</textarea>
Is this OOP, GP, functional, or conventional structured programming?
All of the above: It’s a function template (GP) with a procedural body
(conventional structured) that uses a generic algorithm (GP again) and a
lambda (functional) that takes a pointer to a base class and invokes a
virtual function (OO). The key point is that this is all just
“programming.”<br />
<br />
So today instead of “multiparadigm programming” we should simply say
“programming.” It’s all programming, just using the right language
features together in combination as usual.</div>
Gupta Information Systemshttp://www.blogger.com/profile/18414134095351331587noreply@blogger.com0tag:blogger.com,1999:blog-8525919027680721883.post-12669773908653243432015-04-09T15:06:00.004+05:302015-04-09T15:06:54.148+05:30Is C++ better than Java? (or C#, C, Objective-C, JavaScript, Ruby, Perl, PHP, Haskell, FORTRAN, Pascal, Ada, Smalltalk, or any other language?)<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
Stop. This question generates much <em>much</em> more heat than light. Please read the following before posting some variant of
this question.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
In 99% of the cases, programming language selection is dominated by business considerations, <em>not</em>
by technical considerations. Things that <em>really</em> end up mattering are things like availability of a programming
environment for the development machine, availability of runtime environment(s) for the deployment machine(s),
licensing/legal issues of the runtime and/or development environments, availability of trained developers, availability
of consulting services, and corporate culture/politics. These business considerations generally play a much greater role
than compile time performance, runtime performance, static vs. dynamic typing, static vs. dynamic binding, etc.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Those who ignore the (dominant!) business criteria when evaluating programming language tradeoffs expose themselves to
criticism for having poor judgment. Be technical, but don’t be a techie weenie. Business issues really do dominate
technical issues, and those who don’t realize that is destined to make decisions that have terrible
business consequences — they are dangerous to their employer.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
The most widely circulated comparisons tend to be those written by
proponents of some language, Z, to prove that Z is better that other
languages. Given its wide use, C++ is often top of the list of languages
that the proponents of Z wants to prove inferior. Often, such papers
are “published” or distributed by a company that sells Z as part of a
marketing campaign. Surprisingly, many seem to take an unreviewed paper
written by people working for a company selling Z “proving” that Z is
best seriously. One problem is that there are always grains of truth in
such comparisons. After all, no language is better than every other in
all possible ways. C++ certainly isn’t perfect, but selective truth can
be most seductive and occasionally completely misleading. When looking
at a language comparison consider who wrote it, consider carefully if
the descriptions are factual and fair, and also if the comparison
criteria are themselves fair for all languages considered. This is not
easy.</div>
<div style="text-align: justify;">
Stroustrup refuses to compare C++ to other languages for these reasons given in <a href="http://stroustrup.com/dne.html">The Design and Evolution of C++</a>:</div>
<blockquote>
<div style="text-align: justify;">
<i>“Several reviewers asked me to compare C++ to other languages. This
I have decided against doing. Thereby, I have reaffirmed a
long-standing and strongly held view: Language comparisons are rarely
meaningful and even less often fair. A good comparison of major
programming languages requires more effort than most people are willing
to spend, experience in a wide range of application areas, a rigid
maintenance of a detached and impartial point of view, and a sense of
fairness. I do not have the time, and as the designer of C++, my
impartiality would never be fully credible.</i></div>
<div style="text-align: justify;">
<i>I also worry about a phenomenon I have repeatedly observed in
honest attempts at language comparisons. The authors try hard to be
impartial, but are hopelessly biased by focusing on a single
application, a single style of programming, or a single culture among
programmers. Worse, when one language is significantly better known than
others, a subtle shift in perspective occurs: Flaws in the well-known
language are deemed minor and simple workarounds are presented, whereas
similar flaws in other languages are deemed fundamental. Often, the
workarounds commonly used in the less-well-known languages are simply
unknown to the people doing the comparison or deemed unsatisfactory
because they would be unworkable in the more familiar language.</i></div>
<div style="text-align: justify;">
<i>Similarly, information about the well-known language tends to be
completely up-to-date, whereas for the less-known language, the authors
rely on several-year-old information. For languages that are worth
comparing, a comparison of language X as defined three years ago vs.
language Y as it appears in the latest experimental implementation is
neither fair nor informative. Thus, I restrict my comments about
languages other than C++ to generalities and to very specific comments.”</i></div>
</blockquote>
<br />
<div style="text-align: justify;">
That said, C++ is considered to be the best choice in programming language for a wide variety of people and applications.</div>
</div>
Gupta Information Systemshttp://www.blogger.com/profile/18414134095351331587noreply@blogger.com0tag:blogger.com,1999:blog-8525919027680721883.post-68282518790643374262015-04-09T15:05:00.006+05:302015-04-23T06:47:19.714+05:30Why is C++ so big? <div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
C++ is not a tiny language designed to be a minimal language for
teaching, but neither are the languages people most often compare it to,
such as C, Java, C#. They too are huge compared to say, Pascal as Dr.
Wirth originally defined it – for good reasons. The programming world is
far more complex today than it was 30 years ago, and modern programming
languages reflect that.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
C++ isn’t as big as some people imagine. By word count, the size of the <em>language</em>
specifications (excluding standard libraries) for C++, C#, and Java are
currently within a few percentage points of each other. This reflects
that they are general-purpose mainstream languages that have grown
similar features – <code>auto</code>/<code>var</code> type deduction, range <code>for</code>
loops, lambda functions, various levels of support for generic
programming, and so on. It also reflects what design theorists call
“essential complexity in the problem domain” – the complexity in the
real world and that a serious language has to expose, everything from
fundamental OS differences to calling C++ libraries.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
In some cases C++ directly supports (i.e., in the language) what some
other languages support through libraries, so the language part will be
relatively larger. On the other hand, if you want to write a “typical
modern application”, you need to consider operating system interfaces,
GUI, databases, web interfaces, etc. the sum of language features,
libraries, and programming conventions and standards that you must
become familiar with dwarf the programming language. Here, C++’s size
can be an advantage as far as it better supports good libraries.</div>
<div style="text-align: justify;">
<br /></div>
<br />
<div style="text-align: justify;">
Finally, the days where a novice programmer can know all of a
language are gone, at least for the languages in widespread industrial
use. Few people know “all of C” or “all of Java” either and none of
those are novices. It follows that nobody should have to apologize for
the fact that novices do not know all of C++. What you must do - in any
language – is to pick a subset, get working writing code, and gradually
learn more of the language, its libraries, and its tools. For my
suggestion on how beginners can approach C++, see <a href="http://stroustrup.com/programming.html">Programming: Principles and Practice using C++</a>.</div>
</div>
Gupta Information Systemshttp://www.blogger.com/profile/18414134095351331587noreply@blogger.com0tag:blogger.com,1999:blog-8525919027680721883.post-85564351200663180722015-04-09T15:05:00.002+05:302015-04-23T06:46:42.812+05:30Who uses C++?<div dir="ltr" style="text-align: left;" trbidi="on">
<div style="text-align: justify;">
<a href="http://www.stroustrup.com/applications.html">Lots and</a> <a href="http://www.lextrait.com/vincent/implementations.html">lots of</a>
companies and government sites. Lots. And if you’re using a compiler or
runtime of another language, such as Java, chances are good that it too
is implemented in C++.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
There are too many C++ users to effectively count them, but the
number is in the millions. C++ is supported by all major vendors. The
large number of developers (and therefore the large amount of available
support infrastructure including vendors,
tools, training, etc.) is one of several critical features of C++.</div>
<div style="text-align: justify;">
<br /></div>
<br />
<div style="text-align: justify;">
During 1980-1991, the number of users doubled every seven and a half months (see <a href="http://stroustrup.com/dne.html">The Design and Evolution of C++</a>).
The current growth rate is steady and positive. IDC’s 2001 estimate of
the number of C++ programmers was “about 3 million”; their 2004 number
was “more than 3 million.” That seems plausible and indicates a
continued growth. Especially since about 2010 there is a renewed growth
in C++ as both mobile and datacenter applications value “performance per
Watt” as a new mainstream metric.</div>
</div>
Gupta Information Systemshttp://www.blogger.com/profile/18414134095351331587noreply@blogger.com0