Monday, November 16, 2015

Digest for comp.lang.c++@googlegroups.com - 11 updates in 5 topics

Paul N <gw7rib@aol.com>: Nov 16 03:08PM -0800

On Friday, November 13, 2015 at 1:20:46 PM UTC, Paul wrote:
 
> private:
> object* objArray;
> };
 
The C++ FAQ explains this quite well, which makes me suspect you aren't aware of it. It's at http://www.parashift.com/c++-faq/ and while your immediate question is easy to find, I'd recommend reading much more of it.
woodbrian77@gmail.com: Nov 16 11:33AM -0800

On Monday, November 16, 2015 at 9:03:29 AM UTC-6, Daniel wrote:
> > One presumes class data members would be private, else what's the point of having a class?
 
> > Given that, putting the data members first would be contrary to the generally accepted public, protected, private ordering with a class.
 
> There's at least one practical c++ specific reason for putting the data members first, it makes it easier to line up the constructor initializer lists with the order in which data members are declared, which is a good thing to do in C++.
 
 
I'm not sure why that is easier. To me the main reason to
put data members first has already been mentioned by Alf in
this thread:
 
"And generally, I find it better to declare things before
they're used."
 
That provides a helpful clue to those working on the code.
They know that by scrolling up they will find what they
are looking for.
 
Brian
Ebenezer Enterprises - So far G-d has helped us.
http://webEbenezer.net
Jorgen Grahn <grahn+nntp@snipabacken.se>: Nov 16 09:03PM

On Mon, 2015-11-16, Daniel wrote:
...
 
> usefulness to the developer is vanishing with modern practices using
> templates, inline functions etc., try quickly groking any of the
> standard library or boost classes by glancing at their headers.
 
But those aren't typical classes! It's a major mistake IMO to look
at a standard library implementation or Boost, and think your own
application-specific code has to look that way, too. It doesn't.
 
 
> The problem with const is that it doesn't mean pure, which it would
> have to mean were compilers able to take advantage of it, or
> programmers to reason about it.
 
Who can't reason about const? It's not hard: "const Foo* foo" just
means "I can't use 'foo' to modify anything". True; the name is
misleading.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Bo Persson <bop@gmb.dk>: Nov 16 10:09PM +0100


> That provides a helpful clue to those working on the code.
> They know that by scrolling up they will find what they
> are looking for.
 
Right, unlike scrolling down which is really hard.
 
 
Bo Persson
Vir Campestris <vir.campestris@invalid.invalid>: Nov 16 09:39PM


> That provides a helpful clue to those working on the code.
> They know that by scrolling up they will find what they
> are looking for.
 
People using the code have no business looking in your internal data.
They should be looking at your public methods - so they come first.
 
Andy
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Nov 16 11:27PM +0100

On 11/16/2015 10:39 PM, Vir Campestris wrote:
>> They know that by scrolling up they will find what they
>> are looking for.
 
> People using the code have no business looking in your internal data.
 
That's a weird statement.
 
Someone looking at a class' documentation, where such exists, won't
usually be looking for internal representation. But then, they're not
looking at the code. They're looking at documentation, e.g.
documentation of the standard library, not its code.
 
Looking at the code and using the code is what you do when the
documentation isn't sufficient for what you want to do. Then one would
be very foolish to restrict oneself to the parts of the code providing
the absolutely least information beyond the documentation. There would
be almost no point in that.
 
And for the not uncommon case of undocumented code, looking at only
signatures of public methods will in most cases be insufficient to use a
class, not to mention to change it or derive from it in any way.
 
So, it generally doesn't make sense to avoid looking at representation
when one does look at the code. It doesn't make sense for a
well-documented class. It doesn't make sense for an undocumented class.
 
 
> They should be looking at your public methods - so they come first.
 
This idea is flawed in so many ways.
 
 
Cheers,
 
- Alf
Gareth Owen <gwowen@gmail.com>: Nov 16 05:58PM

> Sent=8,
> Forwarded=16
> };
 
A naked enum is great for flags and lousy for type-safety.
An enum class is lousy for flags and great for type-safety.
 
In C++, use the one that fits your use case!
In C, use the one that exists!
Juha Nieminen <nospam@thanks.invalid>: Nov 16 09:40PM

> #define ERROR_IN_INPUT 1
> #define TOO_LONG_INPUT 2
> #define PARAMETER_ERROR 3
 
Precompiler macros cannot be inside namespaces nor classes,
which means that they effectively contaminate the global
namespace in any file where they are declared.
 
Perhaps the most far-fetched reason for using macros instead
of constants is that the macro doesn't fix the type (which
sometimes is a bad thing, but in a few cases might in fact be
desirable.)
 
However, C++14 variable templates removed even that reason.
(And, in fact, variable templates are even better because you
can define the constant in different ways depending on the type,
and the correct definition will be chosen according to the use.)
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
woodbrian77@gmail.com: Nov 16 09:22AM -0800

On Monday, November 16, 2015 at 7:12:30 AM UTC-6, Alf P. Steinbach wrote:
> >> part of your answer.
 
> > As for practise then i will repeat for such unexperienced weak programmers as you
 
> Google is your friend Vlad
 
https://duckduckgo.com is friendlier as far as search
engines go. They don't track your searches like Google
and others do. They are doing better at saying, "What's
mine is yours and what's yours is yours."
 
Brian
Ebenezer Enterprises - How to tell the 20-trillion-dollar
man that he wouldn't be missed if he resigned?
 
http://webEbenezer.net
SG <s.gesemann@gmail.com>: Nov 16 11:54AM -0800

Am Montag, 16. November 2015 13:42:44 UTC+1 schrieb Vlad from Moscow:
> It is very interesting can you say what are there in the array of 6
> characters that contains a string beyond the five characters?:)
 
I don't understand this question. If you care about me answering it
please try to approximate the English language a little better.
 
> to identify the record. In this case you can declare a character array
> of 5 characters initialized it with either "XML",'\0' or "HTML",'\0'
> and check the identification field as I shwoed in the answer.
 
It appears as if you did not understand what Geoff and I were talking
about. I'll give you the benefit of the doubt and blame it on the
language barrier.
 
> One more for such unquakified programmers as you.
> This is valid correct code.
 
You mean "valid" as in "does not invoke undefined behaviour"? If so:
Yes, sure. It's a perfectly valid program. The question is: Does it
solve the intended problem?
 
$ gcc vlad.c
$ echo aprilaaaa | ./a.out
Enter the key: Correct.
 
I don't think so.
 
 
> It is so obvious that what you are doing is trying to find a reason
> to accuse me and to invent something that to say that my entirely
> correct answer is wrong.:)
 
My main messages to you were:
(1) The program doesn't solve the problem.
(2) You've been acting like a dick judging by the edit history.
 
Though, I can see how some of the downvotes were due to people
thinking your program invokes undefined behaviour because they weren't
familiar with that particular aspect of the C language.
jacobnavia <jacob@jacob.remcomp.fr>: Nov 16 04:47PM +0100

> This is not working under ubuntu 14.04.
 
 
It can't work because _findfirst, etc are WINDOWS functions specific to
the microsoft compiler. The book assumes bloithely that you are under
windows and gives examples that are valid only for windows.
 
Under Ubuntu the thing is a bit more involved. Just look about
"readdir" and you will find more examples of reading a directory under unix
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.

No comments: