Weblogs Forum - Monolith: Facts, Failures, Fallacies, Falsehoods and Furphies

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Monolith: Facts, Failures, Fallacies, Falsehoods and Furphies

26 replies on 2 pages. Most recent reply: Dec 31, 2006 5:06 AM by Antti Tuomi

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 26 replies on 2 pages [ 1 2 | » ]

Matthew Wilson

Posts: 145
Nickname: bigboy
Registered: Jun, 2004

Monolith: Facts, Failures, Fallacies, Falsehoods and Furphies (View in Weblogs)

Posted: Dec 3, 2006 1:19 AM

Reply

Summary
Looking for your best Fs, Fs, Fs, Fs and Fs regarding everyone's favourite (to use, or to moan about) language, C++. If you've got 'em, let me have 'em. The worst that can happen is you'll get a mention in the new book ...

Advertisement

The structure of my new book, Breaking Up The Monolith is pretty much decided, but the content is yet to be "made so". This is particularly the case with the phrasing of the "big questions" I'll be addressing. Lacking in what might kindly be termed linguistic creativity I thought I would instead try and scab some from you, gentle readers. I'm keen to hear from anyone with good or bad experiences with C++.

Let me illustrate with one of each type, to get you started:

Fact: - C++ has become "expert friendly", such that many sophisticated modern libraries would require a PhD in meta-programming to understand them (were it possible at all to digest their utterly opaque implementations).
Failure: - The application of C++'s simplest and most significant mechanism, RAII, has failed to be provided to its full extent by library writers or applied to its full extent by users.
Fallacy: - Propagation of support for C's nul-terminated character strings into the interface-level of C++ components has proven to be a great success.
Falsehood: - Increasing the abstraction level leads to less efficient code.
Furphy ⁽¹⁾: - The standard I/O mechanism is efficient, type-safe and easily extended.

Naturally, no one person will hold all of the above opinions. Indeed, I'm not at this point much interested in examining or debating any of the 5xFs that might be suggested, although I'll doubtless digest any arguments that may be brought forth in support. What I'm really looking for are clearly and succinctly expressed Fs, that tally with the material I'll be covering in the book, which would make bold points in the Preface.

Of course, I allow for the fact that some folks might mention ones that are outside the current scope of the book but that are sufficiently significant that I might amend the plan. :-)

Let rip ...

Furphy is an Australian slang term that roughly means "a false rumour" (probably propagated by a galah who couldn't get his hand off it).

Frank Wilhoit

Posts: 21
Nickname: wilhoit
Registered: Oct, 2003

Re: Monolith: Facts, Failures, Fallacies, Falsehoods and Furphies

Posted: Dec 4, 2006 7:17 AM

Reply

Galahs (aka rose-breasted cockatoos) don't have hands...?

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: Monolith: Facts, Failures, Fallacies, Falsehoods and Furphies

Posted: Dec 4, 2006 11:20 AM

Reply

Off the top of my head I have a couple.

Failure: The C++ Standards Committee is slow to make changes to the core langugage or add libraries. For example, people have been using boost for years now and finally some of the functionality from the boost libraries will make it into the language. I'm thinking specifically of things like regex, smart pointers, etc. that solve real problems for real programmers (one of the tenets Stroustrup constantly sites when talking about C++ :-) and have been a part of most core languages or their standard libraries for years, if not a decade or more, now.

Fallacy: Resource management in C++ is hard. People usually refer to memory specifically and C style strings when making this sort of statement. There is no reason for this using anything that resembles modern C++. To me this is tied directly to the Failure mentioned about RAII. Personally I think it is a fantastic resource management mechanism and I wrote a short article about it here. http://www.janitorprogrammer.com/cppresources.html

I suppose I can also add a Fact as well. At least it is my opinion ;-)

Fact: MFC and COM have warped most people's sense about how hard C++ is. Most of the complaints I have gotten from people about C++ in my career can be traced back to MFC or COM support. I don't have any specific examples to back this up. Maybe somebody else will.

Cookie Raver

Posts: 3
Nickname: theraver
Registered: Dec, 2006

Re: Monolith: Facts, Failures, Fallacies, Falsehoods and Furphies

Posted: Dec 4, 2006 2:32 PM

Reply

You forgot another F category: Fluffs (missed opportunities)

Under that category:
- prescribing an ABI per-platform
- addressing calling conventions

Cookie Raver

Posts: 3
Nickname: theraver
Registered: Dec, 2006

Re: Monolith: Facts, Failures, Fallacies, Falsehoods and Furphies

Posted: Dec 4, 2006 2:40 PM

Reply

> You forgot another F category: Fluffs (missed
> opportunities)
>
> Under that category:
> - prescribing an ABI per-platform
> - addressing calling conventions

btw, am aware you wrote about these in ImperdfectC++. You will be adding something new in Monolith?

Matthew Wilson

Posts: 145
Nickname: bigboy
Registered: Jun, 2004

Re: Monolith: Facts, Failures, Fallacies, Falsehoods and Furphies

Posted: Dec 4, 2006 9:55 PM

Reply

> Galahs (aka rose-breasted cockatoos) don't have hands...?

I was tempted to say Dill. But that'd have been a double entendre layered over an insinuation, and not I'm that perverse. ;-)

Matthew Wilson

Posts: 145
Nickname: bigboy
Registered: Jun, 2004

Re: Monolith: Facts, Failures, Fallacies, Falsehoods and Furphies

Posted: Dec 4, 2006 10:06 PM

Reply

> > You forgot another F category: Fluffs (missed
> > opportunities)
> >
> > Under that category:
> > - prescribing an ABI per-platform

Yes, that's a biggie. Not sure that there's any room within the scope of Monolith to address that. I would have to respectfully refer the gentle reader to Part 2 of Imperfect C++ (http://imperfectcplusplus.com), which, as you say, addresses the issue at some length (albiet necessarily incompletely)

> > - addressing calling conventions

Yes, indeed. In fact I'll be talking about calling conventions in Monolith, in terms of how to deal with overloading when binding functions.

Both the scoped_handle and dl_call components involve this.

The former is an allocation-free, polymorphism-free calling convention-aware resource scoping class; see http://www.stlsoft.org/doc-1.9/classstlsoft_1_1scoped__handle.html for some examples; none of these show it, but it works just as well with the (Windows) calling conventions StdCall and FastCall. Naturally, it's virtually cost free. :-)

The latter is a ... well it's better described here: http://www.stlsoft.org/doc-1.9/group__group____library____dl.html#section__library__dl__functions

Feel free to offer any comment/criticism on either of these (or their documentation), as it'll help with the book. ;-)

Matthew Wilson

Posts: 145
Nickname: bigboy
Registered: Jun, 2004

Re: Monolith: Facts, Failures, Fallacies, Falsehoods and Furphies

Posted: Dec 4, 2006 10:16 PM

Reply

> Off the top of my head I have a couple.

Thanks

> Failure: The C++ Standards Committee is slow to make
> changes to the core langugage or add libraries. For
> example, people have been using boost for years now and
> finally some of the functionality from the boost libraries
> will make it into the language. I'm thinking specifically
> of things like regex, smart pointers, etc. that solve real
> problems for real programmers (one of the tenets
> Stroustrup constantly sites when talking about C++ :-) and
> have been a part of most core languages or their standard
> libraries for years, if not a decade or more, now.

That's a fair point. Not sure how I could use it. Although ... the book's high on cohesion while (very) low on coupling. The point can be made that the application of techniques that achieve this can help to mitigate the glacial pace of change and the N-ary bifurcation of "standard" and the portability problems that ensue.

> Fallacy: Resource management in C++ is hard. People
> usually refer to memory specifically and C style strings
> when making this sort of statement. There is no reason for
> this using anything that resembles modern C++. To me this
> is tied directly to the Failure mentioned about RAII.
> Personally I think it is a fantastic resource management
> mechanism and I wrote a short article about it here.
> http://www.janitorprogrammer.com/cppresources.html

Agreed. The scoped_handle component - see other post reply for details - helps me out enormously with local scope RAII. It pretty much eliminates the need to write scoping classes for specific cases (and avoids some of the obfuscatory/inefficient tactics of some other approaches).

Not yet read your article, but I will do!

> I suppose I can also add a Fact as well. At least it is my
> opinion ;-)
>
> Fact: MFC and COM have warped most people's sense about
> how hard C++ is. Most of the complaints I have gotten from
> people about C++ in my career can be traced back to MFC or
> COM support. I don't have any specific examples to back
> this up. Maybe somebody else will.

I agree with MFC. Awful stuff.

Not so sure about COM thought. But then I came to COM _after_ I learnt a lot about C++, so maybe I'm biased. I'd be interested if you could expand this point a bit.

Cheers

Matthew

Cookie Raver

Posts: 3
Nickname: theraver
Registered: Dec, 2006

Re: Monolith: Facts, Failures, Fallacies, Falsehoods and Furphies

Posted: Dec 4, 2006 11:44 PM

Reply

> The latter is a ... well it's better described here:
> http://www.stlsoft.org/doc-1.9/group__group____library____dl.html#section__library__dl__functions
>

This looks pretty impressive. But is it just Windows-specific?

How long have you had this in STLSoft? I could've used it many times.

> The former is an allocation-free, polymorphism-free
> calling convention-aware resource scoping class; see
> http://www.stlsoft.org/doc-1.9/classstlsoft_1_1scoped__handle.html for some examples; none of these show it, but it
> works just as well with the (Windows) calling conventions
> StdCall and FastCall. Naturally, it's virtually cost free.
> :-)
>
> Feel free to offer any comment/criticism on either of
> these (or their documentation), as it'll help with the
> book. ;-)

What does scoped_handle offer that boost::shared_ptr or scopeguard do not?

Rupert Kittinger-Sereinig

Posts: 21
Nickname: rkit
Registered: Dec, 2005

Re: Monolith: Facts, Failures, Fallacies, Falsehoods and Furphies

Posted: Dec 5, 2006 2:29 PM

Reply

> > > You forgot another F category: Fluffs (missed
> > > opportunities)
> > >
> > > Under that category:
> > > - prescribing an ABI per-platform
>
> Yes, that's a biggie. Not sure that there's any room
> within the scope of Monolith to address that. I would have
> to respectfully refer the gentle reader to Part 2 of
> Imperfect C++ (http://imperfectcplusplus.com), which, as
> you say, addresses the issue at some length (albiet
> necessarily incompletely)
>
> > > - addressing calling conventions
>
> Yes, indeed. In fact I'll be talking about calling
> conventions in Monolith, in terms of how to deal with
> overloading when binding functions.
>
> Both the scoped_handle and dl_call components involve
> this.
>
> The former is an allocation-free, polymorphism-free
> calling convention-aware resource scoping class; see
> http://www.stlsoft.org/doc-1.9/classstlsoft_1_1scoped__hand
> le.html for some examples; none of these show it, but it
> works just as well with the (Windows) calling conventions
> StdCall and FastCall. Naturally, it's virtually cost free.
> :-)
>
> The latter is a ... well it's better described here:
> http://www.stlsoft.org/doc-1.9/group__group____library____d
> l.html#section__library__dl__functions
>
> Feel free to offer any comment/criticism on either of
> these (or their documentation), as it'll help with the
> book. ;-)

so here comes some (hopefully constructive) criticism of the documentaion of scoped_handle :-)

I do not like these examples:

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

::stlsoft::scoped_handle<FILE*>  h2(file, ::fclose);

because the resulting code will not check the return value of close() resp. fclose(). This can easily lead to unrecognized data loss.

Closing files is a bit problematic with RAII. Imagine an error occurs while the destructor is running. There is no return value, we can throw no exception, and there is no object left that we might check.

So at the very least, we should provide a custom deleter function/object that checks the result of closing the file and logs an error if something goes wrong. If data integrity is important, calling fsync()/fflush() (and checking the result!) might also be a good idea.

cheers,
Rupert

Matthew Wilson

Posts: 145
Nickname: bigboy
Registered: Jun, 2004

Re: Monolith: Facts, Failures, Fallacies, Falsehoods and Furphies

Posted: Dec 5, 2006 9:36 PM

Reply

> I do not like these examples:
>
>

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

>
> because the resulting code will not check the return value
> of close() resp. fclose(). This
> can easily lead to unrecognized data loss.
>
> Closing files is a bit problematic with RAII. Imagine an
> error occurs while the destructor is running. There is no
> return value, we can throw no exception, and there is no
> object left that we might check.

This is a very good point, and one which is more involved than either of us want to get into here.

I'm going to note this down for the book, and make sure to discuss the problems you've raised.

For now, I'll just amend the examples in the doco to pretend like the issue doesn't exist. ;-) (I'll mention the issue in the docs as well, don't worry.)

It's also worth noting that in many (most??) cases, closing a file in this way, i.e. without checking, is a reasonable tactic, and that something such as scoped_handle is a very helpful tool in that regard. Clearly, what's not reasonable is to not mention that it's not always reasonable: sometimes RAII is not the appropriate approach.

Thanks

Matthew

Rupert Kittinger-Sereinig

Posts: 21
Nickname: rkit
Registered: Dec, 2005

Re: Monolith: Facts, Failures, Fallacies, Falsehoods and Furphies

Posted: Dec 6, 2006 1:40 PM

Reply

> > I do not like these examples:
> >
> >

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

> >
> > because the resulting code will not check the return
> value
> > of close() resp. fclose().
> This
> > can easily lead to unrecognized data loss.
> >
> > Closing files is a bit problematic with RAII. Imagine
> an
> > error occurs while the destructor is running. There is
> no
> > return value, we can throw no exception, and there is
> no
> > object left that we might check.
>
> This is a very good point, and one which is more involved
> than either of us want to get into here.
>
> I'm going to note this down for the book, and make sure to
> discuss the problems you've raised.
>
> For now, I'll just amend the examples in the doco to
> pretend like the issue doesn't exist. ;-) (I'll mention
> the issue in the docs as well, don't worry.)
>
> It's also worth noting that in many (most??) cases,
> closing a file in this way, i.e. without checking, is a
> reasonable tactic, and that something such as
> scoped_handle is a very helpful tool in that regard.
> Clearly, what's not reasonable is to not mention that it's
> not always reasonable: sometimes RAII is not the
> appropriate approach.
>
> Thanks
>
> Matthew

I have thought about this a little more, and I found the following: there are actually two different resources involved, the file handle and the file content. It is the the design of close()/fclose() that is problematic, because it mixes two different operations: buffer flushing and file handle deallocation. If we perform fsync()/fflush()/shutdown() so that the the only task that is left is releasing the file handle, the problem disappears, and scoped_handle can be used without regret.

So maybe we can extrapolate from this case and get the following rule of thumb:

Think twice about using RAII if the deallocation function perfoms more than one task at once.

Finally, if data consistency is really important, using a database may be simpler :-)

cheers,
Rupert

Thomas Guest

Posts: 236
Nickname: tag
Registered: Nov, 2004

Re: Monolith: Facts, Failures, Fallacies, Falsehoods and Furphies

Posted: Dec 6, 2006 2:52 PM

Reply

Furphy

"The C++ compiler catches bugs at compile time."

It doesn't: it catches syntax errors.

Matthew Wilson

Posts: 145
Nickname: bigboy
Registered: Jun, 2004

Re: Monolith: Facts, Failures, Fallacies, Falsehoods and Furphies

Posted: Dec 6, 2006 7:58 PM

Reply

> Furphy
>
> "The C++ compiler catches bugs at compile time."
>
> It doesn't: it catches syntax errors.

Nice. Thanks

Matthew Wilson

Posts: 145
Nickname: bigboy
Registered: Jun, 2004

Re: Monolith: Facts, Failures, Fallacies, Falsehoods and Furphies

Posted: Dec 6, 2006 8:00 PM

Reply

> I have thought about this a little more, and I found the
> following: there are actually two different resources
> involved, the file handle and the file content. It is the
> the design of close()/fclose()
> that is problematic, because it mixes two different
> operations: buffer flushing and file handle deallocation.
> If we perform fsync()/fflush()/shutdown() so that the the
> only task that is left is releasing the file handle, the
> problem disappears, and scoped_handle can be
> used without regret.
>
> So maybe we can extrapolate from this case and get the
> following rule of thumb:
>
> Think twice about using RAII if the deallocation function
> perfoms more than one task at once.

This is some good thinking. Thanks!

Flat View: This topic has 26 replies on 2 pages [ 1 2 | » ]

Previous Topic

Next Topic

Sponsored Links

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use