The Artima Developer Community
Sponsored Link

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

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

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 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 7:03 AM
Reply to this message 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 9:33 AM
Reply to this message 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 9:53 AM
Reply to this message 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 10:50 AM
Reply to this message 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 6:02 PM
Reply to this message 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 6:04 PM
Reply to this message 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 10:04 PM
Reply to this message 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 3:09 AM
Reply to this message 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 6:08 PM
Reply to this message 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 6:53 PM
Reply to this message 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 11:18 AM
Reply to this message 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 8:06 AM
Reply to this message 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 ]
Topic: Monolith: Facts, Failures, Fallacies, Falsehoods and Furphies Previous Topic   Next Topic Topic: The


Sponsored Links



Google
  Web Artima.com   

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