The Artima Developer Community
Sponsored Link

Weblogs Forum
The Elephant in the Living Room

38 replies on 3 pages. Most recent reply: May 2, 2005 6:11 PM by Terje Slettebø

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 38 replies on 3 pages [ 1 2 3 | » ]
Matthew Wilson

Posts: 145
Nickname: bigboy
Registered: Jun, 2004

The Elephant in the Living Room (View in Weblogs)
Posted: Apr 10, 2005 8:27 AM
Reply to this message Reply
Summary
C++ is too complex? Or just super-powerful? Or a confusing mix of both truths, not amenable to being tied down and categorised? There's an elephant wandering round the living room, and it's time someone offered it a chair. (Or a bun.)
Advertisement

In the mid-1990s I had the jaw-sagging gall, not to mention incredible naivety, to think that I knew almost all of C++. I can actually remember a conversation with a similarly humility-challenged friend where we estimated that we probably knew 98% of C++. A couple of weeks later I read an article about the new mutable keyword, and it's been downhill ever since.

In recent years C++ has gone "Modern", which means to say very powerful but also, alas, very esoteric and undiscoverable. If you've written a non-trivial template library involving any kind of meta-programming, then you've likely learned a lot, and got yourself a very powerful tool. However, it's equally likely that you've created something impenetrable to all but the most ardent and cunning code explorers.

What's to be done about this situation? This is the basis of my current interest in C++. I do not have the right answer, and I'm not convinced I'm going to find it, but I do know lots of wrong ones. The fruits of this search - assuming there'll be some - are the parts of my next book, Extended STL, that are as yet unwritten. Unfortunately, or maybe fortunately, I suspect they'll also be the most important (non-technical) parts.

Use policies for everything? The computer says eh-erh! Portability: compromised. Efficiency: compromised. Discoverability: plummets with each template parameter.

Rely on standards This is the approach of the STL, and it works very well. Unfortunately it's quite fragile and limiting. Containers, iterators and algorithms: Great! Adaptors and function objects: not so great! There are a host of alternative approaches, such as Eric Niebler's FOR_EACH, mine and John Torjo's Ranges (which can handle collection types beyond the limitations of the STL), Lamba, etc. But all of these have problems of their own, the most significant of which I'd suggest is that they're complex and impenetrable.

Get the compiler to deduce the lot This involves using TMP to detect, deduce, decode and diagnose all your problems. Alas, there's no better way to expose compiler inconsistencies and limitations. Nor of losing your potential user base: discoverability hits -ve values.

Live with the current limitations In some ways, this is the best approach. Perhaps we, as C++ programmers, spend too much time looking for neat new ways of programming instead of doing neat new programming of new things? Maybe it's because I'm a library writer, but sometimes it feels like I'm just spending my time discovering new gaits to running at a standstill. Perhaps the anachronistic, gauche, peurile, boring, constrained kind of programming that one must need perform in Java and .NET is better in the long run, because one stops worrying about smart new ways of extending the language, and just gets on with programming the task at hand?

It looks pretty negative. So why do I spend most of each working day doing and enjoying C++ design and development? It's powerful, it's efficient, it can be wonderfully expressive, and it's fun. But it can be just so hard. Does it have to be that hard? I look forward to hearing your thoughts. (And if they're useful, they could end up in Extended STL and you could end up having a gruff Yorkshireman in your debt. )


Keith Ray

Posts: 658
Nickname: keithray
Registered: May, 2003

Re: The Elephant in the Living Room Posted: Apr 10, 2005 12:04 PM
Reply to this message Reply
I used to be a master of C++ too, even serving as a team's C++ "language lawyer"... As the language has become more esoteric, I have purposefully avoided getting into the rat-hole of meta-programming in favor of "real" programming.

Now that I'm back on the Mac doing Cocoa programming, I'm getting more work done with less keyboarding because I can use Objective-C and C++... Objective-C has more run-time "power" and flexibility than C++.

At http://patricklogan.blogspot.com/2005/04/simplest-overlooked-things.html , Patrick Logan reminds us how easy it is to integrate Objective-C's first-class objects with Python, Ruby, Java, Smalltalk/Fscript, AppleScript: integration that does not require, for the most part,
the massive amounts of code-generation that integrating C++ objects to other systems would require, but instead using the reflection capabilities build into these languages' runtimes.

Smalltalk and Ruby's "blocks" (closures) provide a lot of power in a much more simple manner than C++ metaprogramming provides... besides passing a block around to classes and methods, you can implement new methods on blocks, to provide new control structures. This page, http://www.cincomsmalltalk.com/userblogs/mls/blogView?showComments=true&entry=3289922530 , provides some sample of the interesting and powerful things you can do with blocks.

Smalltalk, Ruby, Python, and Objective-C have ways for a class to intercept "invalid" method calls and do useful things with them - such as forwarding the call over a network (a network-proxy via a single method). To do network proxies in C++ requires code-generation or extensive amounts of template programming. These pages, http://www.cincomsmalltalk.com/userblogs/travis/blogView?searchCategory=Smalltalk:%20doesNotUnderstand: show a few of the powerful and flexible things that can be done with this interception capability that would require re-writing the compiler in another language.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: The Elephant in the Living Room Posted: Apr 10, 2005 1:40 PM
Reply to this message Reply
> Does it have to be that hard?

Most definitely not. C++ can be as clean, elegant and discoverable as Ruby or Python. I think many experienced C++ programmers make C+++ too complicated, because they won't let themselves write libraries which are simply good enough, and are inflexible with regards to exchanging efficiency and portability for ease of use and speed of development.

It may seem strange to advocate writing inefficient libraries, but I am simply suggesting that C++ programmers need to know when good is good enough. I believe that the an important part of being a software developer is to know where to draw that line.

For instance I believe Matthew is one of the leading C++ portability expert in the world (not something I say lightly).

His C++ code is tested on literally dozens of C++ compilers simultaneously, but even for someone as clever and knowledgable as himself, all of that effort still takes a lot of time and energy.

I hypothesize this is why he and many other experienced C++ programmers start taking such an active interest in languages like Ruby/Python/D. These languages don't have the same portabilitiy issues because they are supported on much fewer platforms, have far fewer implementations, as well as having a myriad of other restrictions (due mainly to their relative immaturity).

I think it comes down to the fact the the key to productivity and elegance is restraint. We can either rely on a language to provide it for us, or we can do it ourselves. For example it is hard to do functional programming using idiomatic C++, but if we restrict oureselves to using only two kinds of types: for instance Atom and List, and only use functions with the
signature: Atom function(AtomList& x) { } functional programming becomes almost trivial.

Anyway, I hope to eventually prove through my own work on the OOTL (and the continued help and guidance of Matthew) that with the right libraries C++ can be wielded just as effectively as any other high-level language.

Harrison Ainsworth

Posts: 57
Nickname: hxa7241
Registered: Apr, 2005

Re: The Elephant in the Living Room Posted: Apr 10, 2005 3:48 PM
Reply to this message Reply
First, one must know that one is using C++ for the right purpose. Its salient features are valuable: efficiency (in speed and space), strong typing, object-orientation, popularity. With those in mind it has scarcely any competitors, and is, and seems, a very good language. And one can accept its character as an 'engineered' language -- built to meet functional needs, rather than to be cosy for the programmer.

The complexity is very much solved by following idiomatic forms. We have Stroustup's comments and Meyer's books, and others, to start from. Eventually a limited set of familiar structures emerges in our programming behaviour. It really does feel easy then. I think this is the key strategy: educing and promulgating limited, evolved, proven patterns of C++ usage.

Templates seem the least portable and most awkward part of the language. For general development I avoid them as much as possible. That's blunt, but mostly appropriate. Stroustrup avers somewhere that one shouldn't seek to use all the language all the time.

Library making is just more demanding, though. However, I imagine the tactic is more of the same approaches, distilled and delivered, I hope, in material like 'Extended STL'.

I spent a while using other languages like Java, Ruby, JavaScript, and found their attractions. But they don't have what C++ has, and that's given me a refreshed appreciation of it.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: The Elephant in the Living Room Posted: Apr 10, 2005 5:16 PM
Reply to this message Reply
> It may seem strange to advocate writing inefficient
> libraries, but I am simply suggesting that C++ programmers
> need to know when good is good enough. I believe that the
> an important part of being a software developer is to know
> where to draw that line.

I agree, however I think that C++ invites this (as would any other language that presents wide palette of non-algorithmic optimization options). It's just too inviting to tinker and find the fastest way to do something without sacrificing abstraction. So, we end up with lots of lore like "here's a cool way of doing something and I saved a dispatch too."

Optimization is great, when you need to do it, but people forget the 95% of cases where you don't have to optimize that one particular thing. As a result, the state-of-the-art has become captivated by these performance explorations.

Matthew Wilson

Posts: 145
Nickname: bigboy
Registered: Jun, 2004

Re: The Elephant in the Living Room Posted: Apr 10, 2005 7:16 PM
Reply to this message Reply
Very true, but there's also a certain physical shake-up coming our way, in which optimisation might see a renaissance. See http://www.gotw.ca/publications/concurrency-ddj.htm

Matthew Wilson

Posts: 145
Nickname: bigboy
Registered: Jun, 2004

Re: The Elephant in the Living Room Posted: Apr 10, 2005 7:26 PM
Reply to this message Reply
> I used to be a master of C++ too, even serving as a team's
> C++ "language lawyer"... As the language has become more
> esoteric, I have purposefully avoided getting into the
> rat-hole of meta-programming in favor of "real"
> programming.

That's a valid perspective, if you see all MP as a rat-hole. The point I'm trying to make, whence the crux of the dilemma, is ones own TMP is often eminently reasonable, tractable, discoverable. It's just that everybody else's is a hideous impenetrable blob. Naturally this is probably something fundamental in the language - i.e. the emergent nature of C++'s TMP facilities, rather than having been a designed-in feature - but that doesn't help any with the dilemma. I can do great things with my classes with my own dialect of TMP. And so can everyone else. So the temptation to do those things is very hard to resist.

> At
> http://patricklogan.blogspot.com/2005/04/simplest-overlooke
> d-things.html , Patrick Logan reminds us how easy it is to
> integrate Objective-C's first-class objects with Python,
> Ruby, Java, Smalltalk/Fscript, AppleScript: integration
> that does not require, for the most part,
> the massive amounts of code-generation that integrating
> C++ objects to other systems would require, but instead
> using the reflection capabilities build into these
> languages' runtimes.

Interesting. I don't know if you follow my CUJ column - Positive Integration - wherein I examine issues of integrating C and C++ with other languages, but my tendency has been very much to draw a veil of straight C around a C++ implementation, in order that integration is trivial. And all my Python and Ruby mappings are written in straight C. I'd never thought about that in this light. I guess that's backing up your argument. :-)

> Smalltalk and Ruby's "blocks" (closures) provide a lot of
> power in a much more simple manner than C++
> metaprogramming provides... besides passing a block around
> to classes and methods, you can implement new methods on
> blocks, to provide new control structures. This page,
> http://www.cincomsmalltalk.com/userblogs/mls/blogView?showC
> omments=true&entry=3289922530 , provides some sample of
> the interesting and powerful things you can do with
> blocks.

Indeed. That's one of the reasons I love Ruby.

Matthew Wilson

Posts: 145
Nickname: bigboy
Registered: Jun, 2004

Re: The Elephant in the Living Room Posted: Apr 10, 2005 7:36 PM
Reply to this message Reply
> First, one must know that one is using C++ for the right
> purpose. Its salient features are valuable: efficiency (in
> speed and space), strong typing, object-orientation,
> popularity. With those in mind it has scarcely any
> competitors, and is, and seems, a very good language. And
> one can accept its character as an 'engineered' language
> -- built to meet functional needs, rather than to be cosy
> for the programmer.

No argument there.

> The complexity is very much solved by following idiomatic
> forms. We have Stroustup's comments and Meyer's books, and
> others, to start from. Eventually a limited set of
> familiar structures emerges in our programming behaviour.
> It really does feel easy then. I think this is the key
> strategy: educing and promulgating limited, evolved,
> proven patterns of C++ usage.

Indeed.

> Templates seem the least portable and most awkward part of
> the language.

and yet most powerful.

> For general development I avoid them as much
> as possible. That's blunt, but mostly appropriate.
> Stroustrup avers somewhere that one shouldn't seek to use
> all the language all the time.
>
> Library making is just more demanding, though. However, I
> imagine the tactic is more of the same approaches,
> distilled and delivered, I hope, in material like
> 'Extended STL'.

I hope so.

Perhaps the consternation I'm implying is merely the growing pains of the new C++. And perhaps I'm bothered, and also stimulated, by it by the feeling that I've gone from (the laughably fictional) 98% down to perhaps ~90% in the last decade of lots of C++ working and thinking.

I think you make some good points, and I am heartened by your "limited, evolved, proven patterns of C++ usage.", and more positive about the approach for the book. Thanks. :-)

btw, may I use that quote, should I find a place for it?

Matthew Wilson

Posts: 145
Nickname: bigboy
Registered: Jun, 2004

Re: The Elephant in the Living Room Posted: Apr 10, 2005 8:12 PM
Reply to this message Reply
> > Does it have to be that hard?
>
> Most definitely not. C++ can be as clean, elegant and
> discoverable as Ruby or Python. I think many experienced
> C++ programmers make C+++ too complicated, because they
> won't let themselves write libraries which are simply good
> enough, and are inflexible with regards to exchanging
> efficiency and portability for ease of use and speed of
> development.

I agree that a lot of libraries are inefficient. But I think it's not because they are favouring ease-of-use and speed of development. In fact, with respect, I find that almost laughable. I think what people are unwilling to eschew is intellectual challenge and "power".

I regularly get emails from folks who have undertaken huge effort to encapsulate several roles in one "smart" pointer. One might also say that the current sole example in the standard library - auto_ptr - has taken on too much. (Actually, the next instalment of Smart Pointers with Bjorn Karlsson will say exactly that, and demonstrate a simplification.)

I say this because I tend to do it myself, and I have to smack myself about a fair bit and consider whether something's useful or not.

>
> It may seem strange to advocate writing inefficient
> libraries, but I am simply suggesting that C++ programmers
> need to know when good is good enough. I believe that the
> an important part of being a software developer is to know
> where to draw that line.

I think the issue is to write simple libraries, and I aver that simple libraries are more likely to be efficient, and quicker to develop.

With STLSoft (http://stlsoft.org/) I've tried to take this approach: thus there are a large family of very simple, non-template, scoping classes - most employing immutable RAII (it cannot be assigned to, only constructed; see Ch 3 of Imperfect C++) - rather than "smart" pointers types that generalise. In the main, these classes are widely appreciated by users, and I have hardly had any requests for feature change, bug fixes, or (he he) documentation.

Naturally, there are a few smarter types, and there's a template class scoped_handle (see <stlsoft/scoped_handle.hpp>) which can handle any calling-convention, any resource-type, any null-value, and without allocating memory or using vtables. (This is the subject of the second Smart Pointers instalment from Bjorn and I, which we'll finish off as soon as we get our fingers out of some other pies.) e.g.

::stlsoft::scoped_handle<int> h1(::open("file.ext"), ::close);

FILE *file = ::fopen("file.ext", "r");
::stlsoft::scoped_handle<FILE*> h2(file, ::fclose);

::stlsoft::scoped_handle<void*> h3(::malloc(100), ::free);

::stlsoft::scoped_handle<BSTR> h3(::SysAllocString(L"And you can handle __stdcall? :-)"), ::SysFreeString);


But the reason it works is that, despite genuine complexity in the implementation, it limits itself to immutable RAII.

When I constrast the implementation of that type with a generic class, Resource_ptr<>, from old libraries of mine circa 1997, which did try to be all things to all people, using, there's a huge difference in simplicity of use. Resource_ptr takes 5 template parameters, scoped_handle takes 1.

typedef Resource_ptr<HANDLE, HANDLE, Win32File_IsNull, FindFirstChangeNotification_Close, Win32File_SetNull> FindFirstChangeNotification_ptr;

Perhaps of more significance, is that since I wrote scoped_handle I've never once had to look in its implementation to use it, nor had any problem with it in use. And I've had no emails from STLSoft users seeking clarification. (It's a relatively new addition, so the absence of problems might just be an absence of use <g>.)

Contrarily, Resource_ptr<> has - since it's in many of the internal libraries of my company - been a constant source of problems, and quite the most baneful component I've ever written. (Maybe I should release it sometime, to show just how badly one can go ... <g>)

> For instance I believe Matthew is one of the leading C++
> portability expert in the world (not something I say
> lightly).

Piffle. (But nice piffle. <g>)

> His C++ code is tested on literally dozens of C++
> compilers simultaneously, but even for someone as clever
> and knowledgable as himself, all of that effort still
> takes a lot of time and energy.

True. Very true. :-(

> I hypothesize this is why he and many other experienced
> C++ programmers start taking such an active interest in
> languages like Ruby/Python/D. These languages don't have
> the same portabilitiy issues because they are supported on
> much fewer platforms, have far fewer implementations, as
> well as having a myriad of other restrictions (due mainly
> to their relative immaturity).
>
> I think it comes down to the fact the the key to
> productivity and elegance is restraint.

Yes! Like Harrison, I think you've hit a key point. Restraint. I guess that's kind of what I've been coming to myself subconsciously, but it's good to hear it from others. :-)

> We can either rely
> on a language to provide it for us, or we can do it
> ourselves. For example it is hard to do functional
> programming using idiomatic C++, but if we restrict
> oureselves to using only two kinds of types: for instance
> Atom and List, and only use functions with the
> signature: Atom function(AtomList& x) { }
> functional programming becomes almost trivial.

Hmmm. Your words intrigue me. Perchance, sir, thou mightest post such a thing on a bloglet of thine own, upon which I could whine, dine, and opine?

> Anyway, I hope to eventually prove through my own work on
> the OOTL (and the continued help and guidance of Matthew)
> that with the right libraries C++ can be wielded just as
> effectively as any other high-level language.

I remain to be convinced, but look forward to seeing you try.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: The Elephant in the Living Room Posted: Apr 10, 2005 11:47 PM
Reply to this message Reply
> > > Does it have to be that hard?
> >
> > Most definitely not. C++ can be as clean, elegant and
> > discoverable as Ruby or Python. I think many
> experienced
> > C++ programmers make C+++ too complicated, because they
> > won't let themselves write libraries which are simply
> good
> > enough, and are inflexible with regards to exchanging
> > efficiency and portability for ease of use and speed of
> > development.
>
> I agree that a lot of libraries are inefficient.

Actually my point is that most of the good C++ libraries are in fact too efficient and portable at the cost of discoverability.

> But I
> think it's not because they are favouring ease-of-use and
> speed of development. In fact, with respect, I find that
> almost laughable.

I did not say that libraries which are inefficient are neccessarily favouring speed of development and ease-of-use.

I would say that if you were indeed being respectful, you would never have characterized any interpretation of someones viewpoint (misguided or not) as laughable! Need I point out that I find this insulting?

Matthew Wilson

Posts: 145
Nickname: bigboy
Registered: Jun, 2004

Re: The Elephant in the Living Room Posted: Apr 11, 2005 12:13 AM
Reply to this message Reply
> > > > Does it have to be that hard?
> > >
> > > Most definitely not. C++ can be as clean, elegant and
> > > discoverable as Ruby or Python. I think many
> > experienced
> > > C++ programmers make C+++ too complicated, because
> they
> > > won't let themselves write libraries which are simply
> > good
> > > enough, and are inflexible with regards to exchanging
> > > efficiency and portability for ease of use and speed
> of
> > > development.
> >
> > I agree that a lot of libraries are inefficient.
>
> Actually my point is that most of the good C++ libraries
> are in fact too efficient and portable at the cost of
> discoverability.

Oh, ok. Perhaps I misunderstood.

In my experience it's rare that one must sacrifice efficiency for portability, but its search certainly can often incur a cost in discoverability.

> > But I
> > think it's not because they are favouring ease-of-use
> and
> > speed of development. In fact, with respect, I find
> that
> > almost laughable.
>
> I did not say that libraries which are inefficient
> are neccessarily favouring speed of development and
> ease-of-use.
>
> I would say that if you were indeed being respectful, you
> would never have characterized any interpretation
> of someones viewpoint (misguided or not) as laughable!
> Need I point out that I find this insulting?

I didn't mean it pejoratively, and it wasn't aimed at you (or anyone) in any case. It was more an "ironically amusing" type thing.

Perhaps it's a cultural disconnect? (Irony runs thick through the blood of the English. It's why we're so pasty-faced.) No offence intended.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: The Elephant in the Living Room Posted: Apr 11, 2005 12:44 AM
Reply to this message Reply
> Oh, ok. Perhaps I misunderstood.
>
> In my experience it's rare that one must sacrifice
> efficiency for portability, but its search certainly can
> often incur a cost in discoverability.

I misunderstood. I thought you meant discoverability as referring to ease of intuitive understanding of code.

My point was simply that striving towards code which is efficient and portabile takes time and usually results in code which is harder to read, use and maintain.

> I didn't mean it pejoratively, and it wasn't aimed at you
> (or anyone) in any case. It was more an "ironically
> amusing" type thing.
>
> Perhaps it's a cultural disconnect? (Irony runs thick
> through the blood of the English. It's why we're so
> pasty-faced.) No offence intended.

I am sorry I took offence then. My irish and viking blood is thick with alcohol, so I must have been being over-sensitive :-)

Harrison Ainsworth

Posts: 57
Nickname: hxa7241
Registered: Apr, 2005

Re: The Elephant in the Living Room Posted: Apr 11, 2005 8:24 AM
Reply to this message Reply
I think there's agreement that: templates seem to be mainly about facilitating efficiency, rather than doing what couldn't otherwise be done. And efficiency costs the (undisciplined) programmer.

I think the template end of C++ also currently appears harder because it's rather divergent from usual languages/programming, and despite the syntax the programmer doesn't really have finished material to work with.

Even after the standard is printed, the language is not finished. Because (from Wittgenstein) "language is a form of life" -- it is not a self-contained logical structure, but a reflection of what humans are and do. In a reduced sense its probably similar in programming. What we do with the language, is the language. And the community hasn't used templates enough to define their culture.

If lack of culture is an impediment, then such things as other languages must be a good source of ideas for template patterns...

> btw, may I use that quote, should I find a place for it?
sure (oh, if only there was a micropayment infrastructure. ok, nanopayments then).

Keith Ray

Posts: 658
Nickname: keithray
Registered: May, 2003

Re: The Elephant in the Living Room Posted: Apr 11, 2005 11:51 AM
Reply to this message Reply
I have been doing some meta programming this weekend. Starting with the objective-c proxy example here ( http://borkware.com/rants/agentm/elegant-delegation/ ) I'm creating a class to log calls into an object's methods. This involves decoding the method signatures in order to log the arguments. I will be able to do something like this:

someObj = [ [ LoggingProxy alloc ] init: someObj ];

to take an existing object and start logging calls to it -- no recompilation of the sources of someObj's class would be needed. I might even be able to call this code from gdb, so my choice to start logging an object could be made at run-time when debugging.

Apple's Objective-C++ lets me use straight C, Objective-C objects/syntax, and C++ objects/syntax, and mix them in the same source files. (With some care due to differences in object-allocation and exception-handling.)

Apple made their modifications of gcc available to the maintainers of gcc (and the sources are probably on developer.apple.com/darwin or opendarwin.org), but the last time I checked, the maintainers of gcc declined to accept those changes and make those modifications available on other platforms.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Why? Posted: Apr 11, 2005 2:02 PM
Reply to this message Reply
"So why do I spend most of each working day doing and enjoying C++ design and development? It's powerful, it's efficient, it can be wonderfully expressive, and it's fun. But it can be just so hard. Does it have to be that hard?"

I asked myself that question years ago when I abandoned the language for application development. C++ is a horrible language for business apps. I see its use for systems programming and libraries and not much else.

Why are smart people attracted to C++? I concluded that its because C++ itself is just the damndest puzzle. Like chess, the number of permutations is astronomical.

In order to understand any single line of a C++ program, you must understand the entire program. You must know what operators are overloaded, what type conversions might be performed, what all of the single argument constructors are that are not marked explicit, any operator type methods, which things are passed by value vs reference, etc.

The addition of a single method can radically change the behavior of the entire program. Thus, I concluded, C++ does not scale to large projects well.

Flat View: This topic has 38 replies on 3 pages [ 1  2  3 | » ]
Topic: Bolt-Ins for Contract and Extension Classes Previous Topic   Next Topic Topic: How to Draft a Pattern


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us