- Overloading based on const - 1 Update
- "Bjarne Stroustrup announces C++ Core Guidelines" - 5 Updates
- using #define vs const int , in error codes - 2 Updates
- Stackoverflow - a fascist web-site. - 2 Updates
- io.h, reading contents of a directory, ubuntu 14.04 - 1 Update
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:
Post a Comment