Thursday, November 12, 2015

Digest for comp.lang.c++@googlegroups.com - 25 updates in 7 topics

Daniel <danielaparker@gmail.com>: Nov 11 06:54PM -0800

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 <nospam@thanks.invalid>: Nov 12 09:22AM

> 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: news@netfront.net ---
"Öö Tiib" <ootiib@hot.ee>: Nov 12 03:57AM -0800

On Thursday, 12 November 2015 11:22:45 UTC+2, Juha Nieminen wrote:
> 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 <nospam@thanks.invalid>: Nov 12 12:58PM

> 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.)
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
woodbrian77@gmail.com: Nov 12 09:45AM -0800

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 <flibbleREMOVETHISBIT@i42.co.uk>: Nov 12 05:51PM

On 12/11/2015 02:54, Daniel wrote:
 
>> 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.
 
>> 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 <flibbleREMOVETHISBIT@i42.co.uk>: Nov 12 05:55PM

On 12/11/2015 12:58, Juha Nieminen wrote:
 
> 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.)
 
You are missing the point. I am talking about AUGMENTING the interface
of a container not REPLACING it.
 
/Flibble
"Öö Tiib" <ootiib@hot.ee>: Nov 12 10:02AM -0800

On Thursday, 12 November 2015 14:58:37 UTC+2, Juha Nieminen wrote:
> > 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.
woodbrian77@gmail.com: Nov 12 10:19AM -0800

On Wednesday, November 11, 2015 at 8:55:07 PM UTC-6, Daniel wrote:
> > need to
> > be Assignable.
 
> You don't lose anything by storing std::addressof(ref) instead, do you?
 
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 <myfirstname@osa.pri.ee>: Nov 12 01:03PM -0600

Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> wrote in
> 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 <danielaparker@gmail.com>: Nov 12 11:18AM -0800

On Thursday, November 12, 2015 at 12:52:02 PM UTC-5, Mr Flibble wrote:
> 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
 
> >> 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.
 
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Nov 12 08:17PM

On 12/11/2015 19:03, Paavo Helde wrote:
> 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!
 
That was just nonsense mate; have you had a stroke?
 
/Flibble
"Öö Tiib" <ootiib@hot.ee>: Nov 11 06:31PM -0800

On Wednesday, 11 November 2015 20:39:26 UTC+2, JiiPee wrote:
 
> ?
> is there some/any benefit for using define here? I thought that was
> C-programming...
 
One benefit can be if those constants are used in '#if' conditions
of preprocessor (that is usually avoided in C++) or in other tools.
 
If the constants are used only in code then it is perhaps good idea to
avoid capitalizing them in screaming caps. Also if these are meant as
selection of values, (like your error codes) then enum is likely best.
legalize+jeeves@mail.xmission.com (Richard): Nov 12 06:21PM

[Please do not mail me a copy of your followup]
 
no@notvalid.com spake the secret code
>> Prefer constants (as you have done) or enums over #define for C++ code
>> bases.
 
>ye I do, but I just see that some people use defines...
 
Yes. Ignore those people and do not emulate or copy them. They are C
programmers. You can do better with C++.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
"J. Clarke" <j.clarke.873638@gmail.com>: Nov 12 06:57AM -0500

In article <87si6wmxgx.fsf@gmail.com>, gwowen@gmail.com says...
 
> So if I can find a history book that gets the genealogy of Henry VIII
> wrong, that proves that Henry VIII didn't exist?
 
> There's masses of evidence of Jesus Christ
 
I keep hearing of these "masses of evidence" but have never seen any
actually presented.
Reinhardt Behm <rbehm@hushmail.com>: Nov 12 09:46PM +0800

J. Clarke wrote:
 
>> There's masses of evidence of Jesus Christ
 
> I keep hearing of these "masses of evidence" but have never seen any
> actually presented.
 
If you believe in such things or entities without any evidence then you
easily believe in the existence of masses of evidence without having seen
any.
 
--
Reinhardt
Daniel <danielaparker@gmail.com>: Nov 12 07:04AM -0800

On Thursday, November 12, 2015 at 8:46:45 AM UTC-5, Reinhardt Behm wrote:
 
> If you believe in such things or entities without any evidence then you
> easily believe in the existence of masses of evidence without having seen
> any.
 
"Jesus saith unto him, Thomas, because thou hast seen me, thou hast believed: blessed [are] they that have not seen, and [yet] have believed."
 
-- Gospel of John, King James Version
 
It's an interesting way of framing an argument : that believing without evidence is a virtue.
 
Daniel
scott@slp53.sl.home (Scott Lurndal): Nov 12 03:22PM


>> There's masses of evidence of Jesus Christ
 
>I keep hearing of these "masses of evidence" but have never seen any
>actually presented.
 
AFAIK, the only close-to-contemporaneous evidence is in
the writings of Josephus, who was born after the date that
christians claim for the crucifixion.
 
Most of the gospels date to 40-100 years after 33CE.
David Brown <david.brown@hesbynett.no>: Nov 12 01:16PM +0100

On 11/11/15 22:24, Ian Collins wrote:
 
>> WOW I didn't expect that. Thanks
 
> It allows one to define a const value in a header, which in C would
> result in multiple definitions.
 
Of course, you can do it in a clear manner that is compatible with C and
C++ by writing "static const int FRA = 1;".
 
At file scope (ignoring C++ namespaces), every declaration or definition
is either "extern" or "static" (though you can't put the "extern" label
directly on a definition). For some silly reason, the C founding
fathers made "extern" the default unless you actively put on "static".
For good but inconsistent reasons, the C++ founding fathers reversed
that default for objects declared "const".
 
My recommendation is that data and functions should either have an
extern declaration (in a header), or an explicit "static".
 
(Putting things in an anonymous namespace in C is effectively the same
as making them "static", IFAIUI.)
jacobnavia <jacob@jacob.remcomp.fr>: Nov 12 02:26PM +0100

Le 11/11/2015 22:24, Ian Collins a écrit :
 
>> WOW I didn't expect that. Thanks
 
> It allows one to define a const value in a header, which in C would
> result in multiple definitions.
 
OK
 
But then you will have multiple definitions of identical static objects
in each file instead of a single definition in a single file.
 
For a single int the difference is negligible but for more complex data
structures it could be the source of quite a bloat in the data segment
isn't it?
David Brown <david.brown@hesbynett.no>: Nov 12 03:53PM +0100

On 12/11/15 14:26, jacobnavia wrote:
 
> For a single int the difference is negligible but for more complex data
> structures it could be the source of quite a bloat in the data segment
> isn't it?
 
It is not a problem, for two reasons.
 
One is that in many cases, you are talking about a simple thing like a
"const int". Because the compiler knows these cannot legally be
changed, it can use immediate addressing modes in code rather than
creating the actual const int object (and of course the value can also
be used in optimisation as it is fixed). Because the compiler knows it
has internal linkage, it does not have to create the const for other
modules - so the object is (almost) never actually created.
 
And if the code being compiled doesn't refer to the const object at all,
absolutely nothing gets created for it - just like a #define or enum
constant.
 
About the only time the const int will be created is if code takes its
address and the compiler can't optimise things away.
 
In cases where you have a more complex const data structure, you would
typically declare it with "extern" in the header file, and only actually
define it in one module. Then just like anything else with external
linkage, it is only created in one object file.
"Robert Crandal" <noreply2me@yahoo.com>: Nov 11 10:01PM -0700

I have my own web site on Host Gator. Host Gator provides
services such as CGI scripting, Cron jobs, Perl scripts, FTP,
and much more.
 
Does anyone know if it's possible to compile and run C++
programs in my own web space? My goal is to run a C++
program that generates new HTML files every day at a
specific time. I hoping that the Cron service can run my
C++ executable on a schedule.
 
Does anyone know if any of this possible? How?
"Öö Tiib" <ootiib@hot.ee>: Nov 12 03:42AM -0800

On Thursday, 12 November 2015 07:01:12 UTC+2, Robert Crandal wrote:
> and much more.
 
> Does anyone know if it's possible to compile and run C++
> programs in my own web space?
 
If your service provider provides a server dedicated to you
then you can run C++ on it. If the server is shared with others
then no. Or at least so I assume reading
http://support.hostgator.com/articles/pre-sales-policies/compatible-technologies
 
> specific time. I hoping that the Cron service can run my
> C++ executable on a schedule.
 
> Does anyone know if any of this possible? How?
 
Ask that from support guys of your service provider.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Nov 12 09:07AM +0100

On 11/11/2015 10:54 PM, Christian Gollwitzer wrote:
 
> [snip]
> After looking up the telegram problem, I could understand
> why you would solve it using your own implementation of pipes.
 
Well that's a difference between Q&A sites like SO, and discussion
groups like clc++: in the Q&A sites (like SO) there's usually LESS than
meets the eye, while in the discussion groups (like clc++) there's often
MORE than meets the eye.
 
Or at least it's so in the periods when the groups work as intended, and
for clc++ it was so originally.
 
Historically clc++ has had two long periods of extreme waywardness. The
first such period almost turned the group into a Windows programming
group, resulting in the creation of the moderated clc++m. In the second
such period, which apparently is just over, the group was dominated by
non-technical people; only Odin knows where they came from.
 
 
> [snip] Implemening pipes in a langugage with coroutines is indeed
> a very simple thing, in fact Python uses generators for almost all for
> loops today.
 
Well, Python probably has some coroutine facility among its included
batteries, but the generators are, as far as I know, all based on
/continuations/. The difference is that a continuation function yields
only in code within that function, so that it only needs a single stack
frame of state, and can be manually "inverted" (by the compiler) to be
expressed as a member function of an object with that state, plus just a
little more. In contrast, a coroutine can yield also within a function
that it calls, or anywhere, which means that it requires its own
full-blown stack: it's more heavy-weight, and a bit more general.
 
 
> Ignoring the "use pipes" requirement, I am still failing to
> see how this is surprisingly difficult.
 
Yes, as I mentioned in the original posting, I also fail to see any
difficulty. So then that's two. I think the lecturer blindly passed on
an evaluation from the 1950's or something.
 
 
> Loading all of the file into memory and working from there, which leaves
> aside all the buffering issues, would also be a correct solution,
> wouldn't it?
 
That would probably be necessary for the more sophisticated approach of
trying to optimize some global measure of nice line-justification.
 
One problem with such an approach is that in a worst case editing can
cause rippling both ways, up and down, trough megabytes of text.
 
Two inter-related and more pressing problems: global justification can
be /unpredictable/ for the user, and it can be so complex that it
attracts bugs. For example, using Microsoft Word I sometimes struggle to
get it to adopt a sensible formatting of a paragraph. Sometimes I have
to insert a manual line break, which is very undesirable because it's
invisible in normal editing and then can wreak havoc with later edits,
especially automated ones such as global search and replace. And
regarding bugs, Word has a tendency to not handle page breaks correctly.
Again that requires manual formatting intervention. :(
 
 
> treat whitespace. In unicode this is a non-trivial problem, since there
> exist non-breaking spaces and spaces with zero-width, direction-changer
> and similar complicated stuff.
 
Yeah. But for sure, using Unicode is necessary to do it at all. And in
Windows that means using wide strings and streams (with proper setup).
 
 
> What happens if you pass more than two arguments or no argument?
> In the latter case I think you are lucky that the code does not invoke UB.
> argv[argc] contains a single NULL byte, i.e. an empty string IIRC.
 
The code does indeed provoke UB if the program is run without an
argument. Such an invocation is a breach of /contract/. When the
contract is breached, anything can happen. This is not a bug. It's
ordinary good design, according to the principles of (1) clear contracts
and (2) not using time on functionality that may never be needed (Knuth
described how a very elaborate piece of code to handle a special case,
lay dormant for several years, and failed on first call).
 
The code expresses the contract very neatly. I chose to express just the
minimal possible contract compatible with the problem requirements.
 
There are several possible more elaborate contracts, e.g. guaranteed
exception for breach, but IMO this kind of usability is irrelevant.
 
 
> [snip]
> This code is almost the same as mine;
 
Well, your code, which was almost identical to my earlier function
"words_to_lines" in the flow based solution, was pretty close to
reasonably shortest -- it just needed a little pruning for the goal of
shortness.
 
 
>> line += (line.length()? L" " : L"") + word;
 
> I don't like treating integers as boolean values; I would rather write
> line.length() > 0, assuming that you did not do that just for brevity?
 
Heh, you caught me. :)
 
 
>> }
 
>> In case you'd think there a missing "return": nope.
 
> I don't understand why you can leave it off
 
"main" is a very special function and among other special properties, it
has a default function result of 0 in both C (since C99, its
§5.1.2.2.3/1, but not in earlier C89/C90) and C++ (since the first
standard C++98, its §3.6.1/5).
 
 
> I believe that this
> solution, at least to the problem as stated, is easier to understand
> than any of your pipeline versions.
 
Oh, there was just 1 pipeline version.
 
And as mentioned, that's the version that's almost identical to your
code, or vice versa. ;-)
 
That's because it expresses the same fundamental idea of treating the
problem as a flow of words between a word extractor and a line composer.
The word flow is the main focus in the code. In contrast, the other two
solutions I posted focused on input lines, and output lines.
 
 
Cheers & hth.,
 
- Alf
Victor Bazarov <v.bazarov@comcast.invalid>: Nov 11 09:51PM -0500

On 11/11/2015 1:27 PM, Lynn McGuire wrote:
> Is there a way to return the name of the class that is being compiled?
 
Return where? From what? To what?
 
C++ has no standard "reflection" mechanism. Maybe your compiler has it,
RTFM.
 
V
--
I do not respond to top-posted replies, please don't ask
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)