Idiots

[Mr Flibble]

Some of the idiotic things that regulars of this newsgroup advocate:

1) Don't use the unsigned integral types despite the fact that the C++
standard library is full of their use.
2) Don't use abstract interfaces (as they advocate against using public
virtual functions).
3) Never derive from standard containers despite the fact that interface
augmentation is useful.
4) Don't use reference members despite the fact that not all classes
need to
be Assignable.
5) Use the memory allocated by std::vector<POD>::reserve() without
constructing elements by bypassing std::vector's modification functions
(e.g. push_back).

Use this newsgroup with caution.

/Flibble

[Alf P. Steinbach]

For once you write something sensible, Leigh, and I agree with you, so far.

The above are absolutes and absolutes are plain stupid in themselves. If
programming could be reduced to simple absolute mechanical rules, then
the robots would be doing most of it now. They're not.

Regarding (1), when it's suitably qualified, you know we disagree. I
advocate using unsigned integral types for bit-fiddling, while you, at
least that's my impression of old, advocate using them wherever an
integral value can't or shouldn't be negative. I advocate just using
properly named signed type for that.

Regarding (2) I find it difficult to think of any qualification that
would make it not-stupid. But it may exist. My failure to think of a
suitable qualification could be due to not recognizing the relevant
situations as manifestations of the problems this rule is meant to avoid.

Regarding (3), some standard containers have protected members. That
means that they're designed to be derived from. These standard
containers do not have virtual destructors, so they're not designed for
polymorphic destruction. But in short, the advice boils down to not
deriving from classes designed to derive from. That's dumb.

Regarding (4), that's just very perplexing.

Regarding (5), ditto: are you sure that's what was advocated?


Cheers,

- Alf

[Gareth Owen]

Mr Flibble <flibbleREM...@i42.co.uk> writes:

> Some of the idiotic things that regulars of this newsgroup advocate:

> 3) Never derive from standard containers despite the fact that interface
> augmentation is useful.

Meh. You can do interface augmentation but you do have to be careful as
there's no virtual destructor.

> 4) Don't use reference members despite the fact that not all classes
> need to be Assignable.

Who the hell advocates that?

> 5) Use the memory allocated by std::vector<POD>::reserve() without
> constructing elements by bypassing std::vector's modification
> functions (e.g. push_back).

Who the hell advocates that?

> /Flibble

[Daniel]

On Wednesday, November 11, 2015 at 4:08:37 PM UTC-5, Mr Flibble wrote:
> Some of the idiotic things that regulars of this newsgroup advocate:
>

> 2) Don't use abstract interfaces (as they advocate against using public
> virtual functions).

Doesn't follow : No public virtual functions does not imply no abstract interfaces.

> 3) Never derive from standard containers despite the fact that interface
> augmentation is useful.

Don't know about never for everybody, but I don't find that helpful myself. If I wanted to augment the interface, I'd make the container a member.

> 4) Don't use reference members despite the fact that not all classes
> need to
> be Assignable.

You don't lose anything by storing std::addressof(ref) instead, do you?

Happy sausages,
Daniel

[Juha Nieminen]

Mr Flibble <flibbleREM...@i42.co.uk> wrote:
> 1) Don't use the unsigned integral types despite the fact that the C++
> standard library is full of their use.

Years ago I used to follow the principle of using the type that most closely
matched the thing being represented. However, this bit me in the posterior
so many times that nowadays I always use signed integers unless there's a
good reason not to.

As an example, the width and height of, for example, a bitmap, or the screen,
cannot be negative. Negative values are nonsensical. Therefore the most
logical type to represent width and height is unsigned.

However, when talking about screen (or bitmap) coordinates, signed values
are usually a necessity. You could quite well draw a sprite or a line
partially outside the screen, which necessitates negative values. Therefore,
if using integrals to represent these pixel coordinates, int is the most
sensible value.

But since you will be using the width and height of the drawing area all
the time for this purpose, you will now be mixing signed and unsigned
integers, which often result in unexpected implicit casts, which often
result in wrong values. (For example, if making floating point calculations
using these variables, you may inadvertently end up with values of over
4 billion instead of some small negative values.)

There are two possible solutions to avoid this problem: Either always
explicitly cast the width and height to signed when using them, or just
do the sensible thing and use signed integrals for the width and height,
even if those variables can never themselves be negative.

And this is just one example of many.

> 2) Don't use abstract interfaces (as they advocate against using public
> virtual functions).

I don't even understand what this is trying to say.

> 3) Never derive from standard containers despite the fact that interface
> augmentation is useful.

I have never found the need to.

(From a design perspective, composition rather than inheritance may often
be the cleaner solution because it means the public interface of your class
remains more minimalistic and focused on the particular task you are trying
to achieve, without all the extraneous baggage that comes from the container.)

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[Öö Tiib]

On Thursday, 12 November 2015 11:22:45 UTC+2, Juha Nieminen wrote:

> Mr Flibble <flibbleREM...@i42.co.uk> wrote:
>
> > 3) Never derive from standard containers despite the fact that interface
> > augmentation is useful.
>
> I have never found the need to.
>
> (From a design perspective, composition rather than inheritance may often
> be the cleaner solution because it means the public interface of your class
> remains more minimalistic and focused on the particular task you are trying
> to achieve, without all the extraneous baggage that comes from the container.)

Important keyword here is 'public'. The 'private' or 'protected' base classes are
considered to be components with different access syntax since those are not
available in public interface. Derived class has to explicitly make that "baggage"
publicly available with public using declarations.

[Juha Nieminen]

Öö Tiib <oot...@hot.ee> wrote:
> Important keyword here is 'public'. The 'private' or 'protected' base classes are
> considered to be components with different access syntax since those are not
> available in public interface. Derived class has to explicitly make that "baggage"
> publicly available with public using declarations.

Is there any reason to use private inheritance instead of composition in this case?

The only thing that private inheritance would do is to, in a sense, contaminate
the namespace of the class itself. (You never know when a future version of the
container will add a name that you were using in your class.)

[woodb...@gmail.com]

On Wednesday, November 11, 2015 at 4:13:57 PM UTC-6, gwowen wrote:

Please don't swear here.

Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net

[Mr Flibble]

On 12/11/2015 02:54, Daniel wrote:
> On Wednesday, November 11, 2015 at 4:08:37 PM UTC-5, Mr Flibble wrote:
>> Some of the idiotic things that regulars of this newsgroup advocate:
>>
>> 2) Don't use abstract interfaces (as they advocate against using public
>> virtual functions).
>
> Doesn't follow : No public virtual functions does not imply no abstract interfaces.

Yes it does follow; an abstract interface with no public virtual
functions requires public functions that call the private virtual
functions. Perhaps you don't know what we generally mean by an abstract
interface?

>
>> 3) Never derive from standard containers despite the fact that interface
>> augmentation is useful.
>
> Don't know about never for everybody, but I don't find that helpful myself. If I wanted to augment the interface, I'd make the container a member.

Making it a member does not augment its interface; making it a member
would require the containing class to forward all of the container's
interface which would be ridiculous.

>
>> 4) Don't use reference members despite the fact that not all classes
>> need to
>> be Assignable.
>
> You don't lose anything by storing std::addressof(ref) instead, do you?

What? Are you insane?

>
> Happy sausages,

First sane thing you have said.

/Flibble

[Mr Flibble]

You are missing the point. I am talking about AUGMENTING the interface
of a container not REPLACING it.

/Flibble

[Öö Tiib]

On Thursday, 12 November 2015 14:58:37 UTC+2, Juha Nieminen wrote:
> Öö Tiib <oot...@hot.ee> wrote:
> > Important keyword here is 'public'. The 'private' or 'protected' base classes are
> > considered to be components with different access syntax since those are not
> > available in public interface. Derived class has to explicitly make that "baggage"
> > publicly available with public using declarations.
>
> Is there any reason to use private inheritance instead of composition in this case?

The reason is different access syntax. It is up to author of class if 'clear()'
or 'm_container.clear()' makes better sense in implementation of his class.

>
> The only thing that private inheritance would do is to, in a sense, contaminate
> the namespace of the class itself. (You never know when a future version of the
> container will add a name that you were using in your class.)

I do not see your point. Let me describe the scenario:

2016) My class 'Sis' privately inherited from 'std::deque<Si>' (that is typedefed as
'Cont' inside of 'Sis') contains a member 'Sis::squeeze()'.

2025) C++2025 adds 'std::deque::squeeze()'. The 'std::deque::squeeze()'
is hidden by 'Sis::squeeze()' in code of 'Sis' but since I knew nothing of it 9
years ago when writing 'Sis' I didn't use it anyway and everything compiles like
it did.

2028) I see that 'std::deque::squeeze()' is neat thing and want to maintain 'Sis' so
its code starts to use it. I simply need to type 'Cont::squeeze()' to call it because
'squeeze()' means Sis::squeeze().

Where I was contaminated by private base? 'clear()' still works like it did.

[woodb...@gmail.com]

I think serialization libraries have difficulty with reference
members. I don't know of any serialization library that has
support for them. I think this is partly because reference
members have to be initialized in the constructor.

>
> Happy sausages,

Some have found bacon, ham and sausages to be
in the same category as smoking and plutonium.

http://www.bbc.com/news/health-34615621


Brian
Ebenezer Enterprises - "Faith is taking the first step
even when you can't see the whole staircase."
-- Martin Luther King Jr.

http://webEbenezer.net

[Paavo Helde]

Mr Flibble <flibbleREM...@i42.co.uk> wrote in
news:T9ydndauuf0oTNnL...@giganews.com:

> On 12/11/2015 02:54, Daniel wrote:
>> On Wednesday, November 11, 2015 at 4:08:37 PM UTC-5, Mr Flibble
>> wrote:
>>> Some of the idiotic things that regulars of this newsgroup advocate:
>>>
>>> 2) Don't use abstract interfaces (as they advocate against using
>>> public virtual functions).
>>
>> Doesn't follow : No public virtual functions does not imply no
>> abstract interfaces.
>
> Yes it does follow; an abstract interface with no public virtual
> functions requires public functions that call the private virtual
> functions. Perhaps you don't know what we generally mean by an
> abstract interface?

There is no public abstract interface and this is a good thing because
this means that the public (concrete) interface is easier to use and
redesign. The "users" of this public interface are the client code pieces
outside of the class.

There is however abstract *protected* interface. The "users" of this
interface are the derived classes. This way both types of users can be
supported without conflicts and the system can be flexibly redesigned
when the need arises.

Of course there are many situations when this design is an overkill and
where a simple public abstract interface would do. Know your tools!

nhth
Paavo

[Daniel]

On Thursday, November 12, 2015 at 12:52:02 PM UTC-5, Mr Flibble wrote:
> >
> an abstract interface with no public virtual
> functions requires public functions that call the private virtual
> functions. Perhaps you don't know what we generally mean by an abstract
> interface?
>

Well,

class A
{
public:
void f()
{
do_f();
}
private:
virtual void do_f() = 0;
}

seems plenty abstract to me. Perhaps you were thinking of a pure virtual class?

> Making it a member does not augment its interface; making it a member
> would require the containing class to forward all of the container's
> interface which would be ridiculous.
>

I recall many years ago reading a column in C++ Report by Scott Meyers titled never derive from a concrete class (which is a bit stronger than never derive from a standard container.) My first thought was that's ridiculous. But the arguments were sufficiently compelling that I incorporated them into my programming practices, I think for the better, and it's extremely rare that I would do that anymore.

If you want to extend the interface, why not use free functions?

I have to say I'm not enthusiastic about people wrapping standard containers, either via derivement or containment. If I'm looking at somebody else's code and see std::map but can't remember the details, I can give that to google, but if I type "MrFlibblesMagicalMap", nothing comes back

> >
> >> 4) Don't use reference members despite the fact that not all classes
> >> need to
> >> be Assignable.
> >
> > You don't lose anything by storing std::addressof(ref) instead, do you?
>
> What? Are you insane?
>

Possibly, not to be ruled out. But whenever I've wanted to hold onto something received in the constructor as a reference, I've held onto the pointer rather than the reference. There are other contexts, of course.

> >
> > Happy sausages,
>
> First sane thing you have said.
>

You know, there are people who say you should *never* eat sausages.

> /Flibble

[Mr Flibble]

That was just nonsense mate; have you had a stroke?

/Flibble

[Mr Flibble]

On 12/11/2015 19:18, Daniel wrote:
> On Thursday, November 12, 2015 at 12:52:02 PM UTC-5, Mr Flibble wrote:
>>>
>> an abstract interface with no public virtual
>> functions requires public functions that call the private virtual
>> functions. Perhaps you don't know what we generally mean by an abstract
>> interface?
>>
> Well,
>
> class A
> {
> public:
> void f()
> {
> do_f();
> }
> private:
> virtual void do_f() = 0;
> }
>
> seems plenty abstract to me. Perhaps you were thinking of a pure virtual class?

It is only abstract in the sense that it has a pure virtual function but
I wouldn't call this (in general) an "interface"; an interface consists
of pure virtual functions and TRIVIAL helper functions only BUT NO CLASS
INVARIANT. Advocating making all the interface's virtual functions
private serves no purpose: in your example f() does nothing other than
call do_f().

Perhaps you are confusing "interface" with "abstract base class"? One
is a subset of the other.

>
>> Making it a member does not augment its interface; making it a member
>> would require the containing class to forward all of the container's
>> interface which would be ridiculous.
>>
> I recall many years ago reading a column in C++ Report by Scott Meyers titled never derive from a concrete class (which is a bit stronger than never derive from a standard container.) My first thought was that's ridiculous. But the arguments were sufficiently compelling that I incorporated them into my programming practices, I think for the better, and it's extremely rare that I would do that anymore.
>
> If you want to extend the interface, why not use free functions?

One indeed should prefer free functions to member functions as adding
public member functions to a class reduces that class's encapsulation
however there are cases when it is appropriate to augment a class's
interface through derivation and advocating that you must NEVER do this
for containers is idiotic (as long as the generality of the container
concept is not compromised).

>
> I have to say I'm not enthusiastic about people wrapping standard containers, either via derivement or containment. If I'm looking at somebody else's code and see std::map but can't remember the details, I can give that to google, but if I type "MrFlibblesMagicalMap", nothing comes back

See comment above.

>
>>>
>>>> 4) Don't use reference members despite the fact that not all classes
>>>> need to
>>>> be Assignable.
>>>
>>> You don't lose anything by storing std::addressof(ref) instead, do you?
>>
>> What? Are you insane?
>>
> Possibly, not to be ruled out. But whenever I've wanted to hold onto something received in the constructor as a reference, I've held onto the pointer rather than the reference. There are other contexts, of course.

If you don't require pointer nullability or modification and object
assignability then there is nothing wrong with using reference members
in fact one should always prefer references to pointers.

>>>
>>> Happy sausages,
>>
>> First sane thing you have said.
>>
> You know, there are people who say you should *never* eat sausages.

Indeed but the majority of those who say that believe in the existence
of magical sky fairies.

/Flibble

[Wouter van Ooijen]

Op 12-Nov-15 om 9:17 PM schreef Mr Flibble:

No stroke required, it is a well-known design pattern:
Non-Virtual-Interface.

Wouter

[Daniel]

On Thursday, November 12, 2015 at 3:29:29 PM UTC-5, Mr Flibble wrote:
>
> It is only abstract in the sense that it has a pure virtual function but
> I wouldn't call this (in general) an "interface"

You mightn't, but Herb Sutter would, he calls it the Non-Virtual Interface Idiom (NVI). Sutter says that Guideline #1 is "Prefer to make interfaces nonvirtual."

>
> > You know, there are people who say you should *never* eat sausages.
>
> Indeed but the majority of those who say that believe in the existence
> of magical sky fairies.
>

My Pakistani friend who identifies as half muslim (he drinks beer but he doesn't eat pork) would respectfully demur.

Daniel

[Mr Flibble]

On 12/11/2015 21:26, Daniel wrote:
> On Thursday, November 12, 2015 at 3:29:29 PM UTC-5, Mr Flibble wrote:
>>
>> It is only abstract in the sense that it has a pure virtual function but
>> I wouldn't call this (in general) an "interface"
>
> You mightn't, but Herb Sutter would, he calls it the Non-Virtual Interface Idiom (NVI). Sutter says that Guideline #1 is "Prefer to make interfaces nonvirtual."

I don't care what Herb Sutter thinks. Have you ever heard of the appeal
to authority logical fallacy? Not that I agree that Herb Sutter is an
authority on such matters. Are you a Herb Sutter fan boy?

>>
>>> You know, there are people who say you should *never* eat sausages.
>>
>> Indeed but the majority of those who say that believe in the existence
>> of magical sky fairies.
>>
> My Pakistani friend who identifies as half muslim (he drinks beer but he doesn't eat pork) would respectfully demur.

Oh.

/Flibble

[Mr Flibble]

Again you are confusing abstract base classes (employing template method
pattern) with pure interfaces. Interfaces are a subset of abstract base
classes and an interface should NOT have any class invariant unlike most
abstract base classes which do.

/Flibble

[Gareth Owen]

woodb...@gmail.com writes:

> On Wednesday, November 11, 2015 at 4:13:57 PM UTC-6, gwowen wrote:
>
> Please don't swear here.

You stop proselytzing and plugging your Middleware writer, and I'll stop
swearing. Deal?

(Also, "hell"? Really? Is it 1860 all of a sudden/)

[Scott Lurndal]

woodb...@gmail.com writes:
>On Wednesday, November 11, 2015 at 4:13:57 PM UTC-6, gwowen wrote:
>
>Please don't swear here.

Mind your own business.

[Daniel]

On Thursday, November 12, 2015 at 5:17:05 PM UTC-5, Mr Flibble wrote:
> On 12/11/2015 21:26, Daniel wrote:
> > On Thursday, November 12, 2015 at 3:29:29 PM UTC-5, Mr Flibble wrote:
> >>
> >> It is only abstract in the sense that it has a pure virtual function but
> >> I wouldn't call this (in general) an "interface"
> >
> > You mightn't, but Herb Sutter would, he calls it the Non-Virtual Interface Idiom (NVI). Sutter says that Guideline #1 is "Prefer to make interfaces nonvirtual."
>
> I don't care what Herb Sutter thinks. Have you ever heard of the appeal
> to authority logical fallacy?

Yes, but that doesn't apply to my argument. To make my point, it is enough to show that there exist members of the C++ community that don't accept your narrow definition of abstract interface, that your's is not a universal understanding of the term within C++ (you haven't been messin' around in .net land lately, have you?)

Do you know about the fallacy of posting too soon after consuming a big plate of sausages?

Daniel

[Mr Flibble]

You did appeal to a perceived authority but your argument was fallacious
for other reasons. In C++ an interface is a type of abstract base class
(i.e. a subset) that contains no class invariant and only pure virtual
functions (or trivial helper functions that call the pure virtual
functions). Advocating that all virtual functions must be private is at
odds with interfaces and is therefore idiotic.

>
> Do you know about the fallacy of posting too soon after consuming a big plate of sausages?

How childish.

/Flibble

P.S. Sausages.

[Daniel]

On Friday, November 13, 2015 at 1:01:56 PM UTC-5, Mr Flibble wrote:
>
> In C++ an interface is a type of abstract base class
> (i.e. a subset) that contains no class invariant and only pure virtual
> functions (or trivial helper functions that call the pure virtual
> functions). Advocating that all virtual functions must be private is at
> odds with interfaces and is therefore idiotic.
>

Source?

[Mr Flibble]

HP Sauce or ketchup with my sausages.

/Flibble

[Daniel]

On Friday, November 13, 2015 at 1:44:56 PM UTC-5, Mr Flibble wrote:
> On 13/11/2015 18:27, Daniel wrote:
> > On Friday, November 13, 2015 at 1:01:56 PM UTC-5, Mr Flibble wrote:
> >>
> >> In C++ an interface is a type of abstract base class
> >> (i.e. a subset) that contains no class invariant and only pure virtual
> >> functions (or trivial helper functions that call the pure virtual
> >> functions).
> >>

> > Source?
>
> HP Sauce or ketchup with my sausages.
>

Fibble-fable nonsense!

Daniel

[asetof...@gmail.com]

) Use the memory allocated by std::vector<POD>::reserve() without
constructing elements by bypassing std::vector's modification functions
(e.g. push_back).

Use this newsgroup with caution.

/Flibble
-------
For me, as the function variables
Malloc function has to
minimize operation alloc -free as a stack too

Example
m=malloc(size)
r=malloc(size)
...
free(r)
free(m)
Minimize free() as 1 operation as
It was in one stack memory operation

One can use the debugger for see
Malloc - free alloc
dealloc
always the same
address ... Or the same set of
address

I don't know if that minimize
malloc instruction 100% for sure.
But it would be good, if one thinking
on the cpu, and memory already load