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 ]

Eivind Eklund

Posts: 49
Nickname: eeklund2
Registered: Jan, 2006

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

Posted: Dec 8, 2006 4:03 AM

Reply

Advertisement

Fallacy: The explictly declared parameter reference syntax of C++ (f(int & a) called as f(a)) makes novice and intermediate programmers hide their intention from the point of call. In other langauges, this is handled either by completely implict reference taking (so the programmers know when something is used as a reference; ie, in Java primitive types are always pass-by-value and object are always pass-by-reference) or (in C) by completely explicit reference taking (f(int *a) called as f(&a)). Both of these mean that you can know more or less what happens at the point of call. With abused C++, you have to know the function/method declaration to find out.

I've even seen the use of f(int & a) - specifically for an int - defended as "information hiding" by a programmer of some 10 years experience with C++.

Roland Pibinger

Posts: 93
Nickname: rp123
Registered: Jan, 2006

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

Posted: Dec 8, 2006 6:33 AM

Reply

> I do not like these examples:

I agree.

>

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

... which would be in the tradition of iostreams :-(
Also, the resource (e.g. FILE*) is not encapsulated and resource management is not automatic: you have to define your scope-guard anew for each function (which is appropriate for certain cases but not in general).

Roland Pibinger

Posts: 93
Nickname: rp123
Registered: Jan, 2006

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

Posted: Dec 8, 2006 6:53 AM

Reply

> It's also worth noting that in many (most??) cases,
> closing a file in this way, i.e. without checking, is a
> reasonable tactic,

Only when the file is opened read-only. Would you use a backup program for your book that doesn't check after close?

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

It is. Also for a 'FileWriter'.


class FileWriter {
public:
   bool open (...);
   bool write (...);
   bool commit();
   void rollback();
};

The destructor calls rollback() unless the user has successfully called commit() before. RAII at its best.

Alex Stojan

Posts: 95
Nickname: alexstojan
Registered: Jun, 2005

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

Posted: Dec 8, 2006 7:50 AM

Reply

Here's another one (could be categorized as 'misguided belief'): C++ should have a standard garbage collector.

Paul Berg

Posts: 3
Nickname: procyon
Registered: Dec, 2006

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

Posted: Dec 8, 2006 3:02 PM

Reply

Failure: C++ template syntax is out of hand. Such a very, very useful mechanism, but such a mess to use.

Failure: C++ syntax in general is so overloaded as to have big issues with ambiguity. >> in template syntax, function pointer syntax, enums and structs sharing namespace but leading to ambiguities, const correctness in multi-referenced pointers (eg, int * can be referenced by a const int *, but an int ** cannot be referenced by a const int **). Seemingly innocuous code can have very surprising results (member function template friend declarations)

Furphie: Multiinheritance leads to more complex code.

Failure: Too much worry about order of construction/destruction and object slicing.

Furphie: Garbage collection is bad
Furphie: Garbage collection is good
Failure: Lack of optional Garbage Collectors

Failure: Allocators

Failure: Namespaces for library versioning

Paul Berg

Posts: 3
Nickname: procyon
Registered: Dec, 2006

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

Posted: Dec 8, 2006 3:04 PM

Reply

Failure: The preprocessor is still a WTF after years and years and years and years of complaining.

Matthew Wilson

Posts: 145
Nickname: bigboy
Registered: Jun, 2004

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

Posted: Dec 11, 2006 7:04 PM

Reply

> Also, the resource (e.g. FILE*) is not encapsulated and
> resource management is not automatic: you have to define
> your scope-guard anew for each function (which is
> appropriate for certain cases but not in general).

Agreed. The whole purpose of the component is to facilitate those occasional cases where one does not have a facade to hand.

Matthew Wilson

Posts: 145
Nickname: bigboy
Registered: Jun, 2004

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

Posted: Dec 12, 2006 12:09 AM

Reply

> Failure: The preprocessor is still a WTF after years and
> years and years and years of complaining.

It is. But I fear that's a little outside the universe of fixability (as it will appear in <= 300 pages). ;-)

Matthew Wilson

Posts: 145
Nickname: bigboy
Registered: Jun, 2004

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

Posted: Dec 12, 2006 3:08 PM

Reply

> Here's another one (could be categorized as 'misguided
> belief'): C++ should have a standard garbage collector.

Can you elucidate a little?

a w

Posts: 1
Nickname: legolas
Registered: Dec, 2006

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

Posted: Dec 21, 2006 3:53 PM

Reply

Failure: Even with STL, a string is still a bunch of bytes, with the implicit rule that it contains ASCII encoded text, and the people only speak English.

Failure: Making generic programming usable, or even just accessible for everyone. The syntax is just... horrible. (Or Fallacy: hiding so much useful stuff behind such horrible syntax).

Failure: GUI

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

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

Posted: Dec 22, 2006 8:18 AM

Reply

> Failure: Even with STL, a string is still a bunch of
> bytes, with the implicit rule that it contains ASCII
> encoded text, and the people only speak English.
>

Maybe a Fallacy that the STL makes string handling easy for non-ASCII character sets?

> Failure: Making generic programming usable, or even just
> accessible for everyone. The syntax is just... horrible.
> (Or Fallacy: hiding so much useful stuff behind such
> horrible syntax).
>

I'd agree with that.

> Failure: GUI

From what I understand that it completely intentional. I'm not sure how you would improve the GUI handling in a generic manner beyond some of the better available cross platform libraries given that every platform has very different ways to manage GUI's.

Given the experience of some other languages picking a windowing environment to include in the standard library and some of the issues this causes (I'm specifically thinking of python's inclusion of Tk, which I think is fine but it drives some people batty.), I would be happier in the long run if C++ left this portion of the language to third party libraries instead of adopting a toolkit or creating yet another standard.

It's definitely an annoyance, especially if you come from Delphi or VB or web programming. But I think failure might be overstating it.

Antti Tuomi

Posts: 4
Nickname: hrnt
Registered: Dec, 2006

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

Posted: Dec 31, 2006 5:06 AM

Reply

> Failure: C++ syntax in general is so overloaded as to have
> big issues with ambiguity. >> in template syntax, function
> pointer syntax, enums and structs sharing namespace but
> leading to ambiguities, const correctness in
> multi-referenced pointers (eg, int * can be referenced by
> a const int *, but an int ** cannot be referenced by a
> const int **). Seemingly innocuous code can have very
> surprising results (member function template friend
> declarations)

What do you mean, what is the problem with multi-referenced pointers? int ** can not be referenced by a const int **, because that would break const correctness. Consider this:


int **ptr = points somewhere;
const int cInt = 5;
const int **cPtr;
cPtr = ptr; // not allowed
cPtr[0] = &cInt // this is legal, cPtr[0] can point to const int.

But after that, ptr[0] points to const int which is not allowed, thus breaking const correctness.

> Failure: Too much worry about order of
> construction/destruction and object slicing.

Can you elaborate about constructors and destructors?

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