| comp.lang.c++@googlegroups.com | Google Groups |  |
| Unsure why you received this message? You previously subscribed to digests from this group, but we haven't been sending them for a while. We fixed that, but if you don't want to get these messages, send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
- BEST C++ book(s) - 7 Updates
- Visual C++ Version 6 (Visual Studio 98) - 5 Updates
- printing elements of stack - 3 Updates
- std::vector<bool> - 5 Updates
- sizeof lambda - 4 Updates
- String's data type - 1 Update
| Robert Hutchings <rm.hutchings@gmail.com>: Sep 19 09:22AM -0700 If you had to pick the best books with which to teach C++ to absolute beginners, what would your choices be? |
| Mr Flibble <flibble@i42.co.uk>: Sep 19 05:46PM +0100 On 19/09/2014 17:22, Robert Hutchings wrote: > If you had to pick the best books with which to teach C++ to absolute beginners, what would your choices be? The best C++ books are the ones that include advice about sausages. /Flibble |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Sep 19 05:19PM On Fri, 2014-09-19, Robert Hutchings wrote: > If you had to pick the best books with which to teach C++ > to absolute beginners, what would your choices be? Absolute beginners as in "haven't done any programming at all"? Stroustrup's "Programming -- Principles and Practice Using C++" must be a strong candidate. I haven't read it, but he's a good author and a good programmer. http://www.stroustrup.com/programming.html /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Christopher Pisz <nospam@notanaddress.com>: Sep 19 02:36PM -0500 On 9/19/2014 11:22 AM, Robert Hutchings wrote: > If you had to pick the best books with which to teach C++ to absolute beginners, what would your choices be? You can usually tell just from skimming a few pages if it contains void main() #include <iostream.h> #include <windows.h> then toss it out, because it won't teach the C++ language. I learned from one of the old 21 days books, but a lot of people seem to hate it, mostly because of the title. I didn't come across anything that would have been shot down in this newsgroup along the way, and always asked in comp.lang.c++ if I needed clarity. I'd have to say 85% of my learning came from the newsgroup and the other 15% was just a matter of learning what I needed to learn, which books did help with. |
| "Osmium" <r124c4u102@comcast.net>: Sep 19 03:32PM -0500 "Christopher Pisz" wrote: > #include <iostream.h> > #include <windows.h> > then toss it out, because it won't teach the C++ language. One of the best books I have has <iostream.h> out the kazoo. _C++ Primer Plus_ by Stephen Prata. The book - the second edition - was written before the standard was approved. I left over two lineal feet of C++ books behind on my last move - that gives you an idea of how rare I think good C++ books are. It's a real challenge to find a book that's a good fit with how your mind works. I would spend several *hours* with the Amazon reviews. |
| Robert Hutchings <rm.hutchings@gmail.com>: Sep 19 02:12PM -0700 > void main() > > #include <iostream.h> > > #include <windows.h> Yes, I agree. Thanks! |
| Robert Hutchings <rm.hutchings@gmail.com>: Sep 19 03:27PM -0700 > a good programmer. > http://www.stroustrup.com/programming.html > /Jorgen Yes, I agree! Thanks Jorgen. |
| David Brown <david.brown@hesbynett.no>: Sep 19 09:46AM +0200 On 18/09/14 17:05, Christopher Pisz wrote: > No, the human fetus never develops gills, tail or a yolk sac, as some > have claimed. <http://en.wikipedia.org/wiki/Prenatal_development> <http://evolution.berkeley.edu/evolibrary/article/evodevo_02> Humans (and other mammals) do not develop full gills, but they have gill slits which form at a similar time and in a similar way to those of fish - but after that point, the development of the fish foetus and the mammal foetus differs (fish get full gills, mammals get lungs). The gill slits then fade away. Yes, we have tails - pictures of early foetuses of humans and other mammals show very clearly that we have significant tails that develop just like many other mammals. But just like for the other great apes, the tail does not continue to develop, and quickly becomes no more than a short internal stub. (You still have it - try slipping on ice and falling hard on your backside, and you will soon realise that you have a tailbone!). Yes, we have a yolk sac. It might look a little different from a chicken egg, but it plays the same role in the early foetal development. None of this means that foetal development holds some kind of record of our evolutionary ancestry - merely that there are some odd stages in foetal development that are easily explained as genetic "leftovers" from early forefathers. As most genetic changes are slow, many bits get left in place even though they no longer play a useful role. If you are going to quote, especially long sections, please give a reference - it is a matter of politeness both to your readers here, and to the original source. And when you are going to reference a web page in its entirety, it is much better to simply give the reference rather than copying-and-pasting. As far as I can see, your source was this: <http://christiananswers.net/q-eden/edn-c024.html> I am happy to discuss these issues with /you/, and with other people in this newsgroup. I am not going to waste time picking through an article written by a third party with a clear agenda of spreading misinformation in order to support their viewpoint, with a total disregard for the science, the evidence and the facts. When you want to read about theology, read articles written by theologists. When you want to read about science, read articles written by scientists. There is a big difference: Theology is written starting from the assumed conclusion, and then attempts to change reality to fit those assumptions - while science starts with the observed facts, and tries to find a conclusion that explains the facts. |
| Christopher Pisz <nospam@notanaddress.com>: Sep 19 10:12AM -0500 On 9/19/2014 2:46 AM, David Brown wrote: > On 18/09/14 17:05, Christopher Pisz wrote: SNIP > attempts to change reality to fit those assumptions - while science > starts with the observed facts, and tries to find a conclusion that > explains the facts. How can you have an argument between two sides if you automatically label one side as wrong? What proves that it is misinformation? Was it the word "christian?" That's the very reason I copied it rather than linked it. I don't think I got it from that site, but who knows, many sites link to the same thing. |
| Mr Flibble <flibble@i42.co.uk>: Sep 19 04:24PM +0100 On 19/09/2014 16:12, Christopher Pisz wrote: > That's the very reason I copied it rather than linked it. > I don't think I got it from that site, but who knows, many sites link to > the same thing. If you all can do is copy/paste then you have lost the argument. /Flibble |
| Balwinder S Dheeman <bdheeman.SANSPAM@outlook.com>: Sep 19 09:23PM +0530 On 09/15/2014 11:13 PM, Bo Persson wrote: > discovers a discrepancy and wins himself a Nobel prize. > And unlike religion, at that point we don't pull out our old books to > prove him wrong. We buy some new books instead. +1 -- Balwinder S "bdheeman" Dheeman (http://bdheeman.BlogSpot.in/) "Working together, works! The proof is GNU/Linux and F/LOSS Projects; Do you too voluntarily work on or contribute to making any difference?" |
| Christopher Pisz <nospam@notanaddress.com>: Sep 19 02:11PM -0500 On 9/19/2014 10:24 AM, Mr Flibble wrote: >>> On 18/09/14 17:05, Christopher Pisz wrote: > If you all can do is copy/paste then you have lost the argument. > /Flibble I can also sing and dance. You make no logical sense at all. Anything we can read results in the loss of an argument? What? |
| Rosario193 <Rosario@invalid.invalid>: Sep 19 06:48AM +0200 >WANT: print stack elements >PROBLEM: No way to print it is possible to print using onhother stack... #include <iostream> #include <stack> int main(void) { std::stack<int> st, v; int r; st.push(10); st.push(11); st.push(12); std::cout << ":STACK:" << std::endl; std::cout << "size = " << st.size() << std::endl; while(!st.empty()) {//r=st.pop(); r=st.top(); st.pop(); std::cout << r << "\n"; v.push(r); } while(!v.empty()) {//r=v.pop(); r=v.top(); v.pop(); st.push(r); } std::cout << std::endl; return 0; } |
| Christian Gollwitzer <auriocus@gmx.de>: Sep 19 07:11AM +0200 Am 17.09.14 12:34, schrieb Jorgen Grahn: >> std::vector<int> st; > That's not a stack in the OP's sense -- but perhaps that was your > point? Yes, it was, you even quoted my statement saying so:) Christian |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Sep 19 05:14PM On Fri, 2014-09-19, Christian Gollwitzer wrote: >> That's not a stack in the OP's sense -- but perhaps that was your >> point? > Yes, it was, you even quoted my statement saying so:) Oops. Indeed I did :-) /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Nobody <nobody@nowhere.invalid>: Sep 19 05:20AM +0100 On Thu, 18 Sep 2014 16:33:07 -0400, AP wrote: > What is wrong with it ? I'm trying to digest Exceptional C++ on the > subject and can't get it ... std::vector<bool> has a relaxed specification relative to a vector of any other type, so that the implementation can store each element as a single bit. Consequently, code which is valid for a vector of any other type (or even for other containers) isn't necessarily valid for std::vector<bool>. The main problem is that std::vector<bool>::reference won't be just "bool&", because you can't have a reference to a bit. Instead, it will be a proxy which emulates a reference by providing "operator bool" and "operator=" methods. Similarly, you can't obtain a pointer to a bit; "&v[i]" will return a pointer to the reference proxy. In turn, there's no guarantee that "i == j" implies "&v[i] == &v[j]" (v[i] and v[j] will probably be different objects which reference the same bit). |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Sep 19 01:08AM -0700 The C++ standards group should have invented a new "bit" or "bbool" (bbool) type for this allowance. Best regards, Rick C. Hodgin |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Sep 19 01:12AM -0700 Oops... (bbool) should have been (bit bool). |
| Paavo Helde <myfirstname@osa.pri.ee>: Sep 19 03:25AM -0500 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote in news:e4a3f336-7b54- > The C++ standards group should have invented > a new "bit" or "bbool" (bbool) type for this > allowance. Unfortunately, sizeof 1/8 is not representable in size_t. Thus, the C++ standards group should have invented a special std::bitvector instead. Cheers Paavo |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Sep 19 01:46AM -0700 On Friday, September 19, 2014 4:25:28 AM UTC-4, Paavo Helde wrote: > Unfortunately, sizeof 1/8 is not representable in size_t. > Thus, the C++ standards group should have invented a special > std::bitvector instead. Yes. That would make it very clear. Best regards, Rick C. Hodgin |
| "AP" <unixpronospam@verizon.net>: Sep 18 11:40PM -0400 WARNING - pure hypotheticals, may be waste of time unless you're interested in what's under the hood of various nifty C++11 implementations You are right. But then, what's the meaning of sizeof lambda ? 1-byte ? Here is a piece of nonsense code : #include <iostream> using namespace std; int main() { auto lambda=[](){ return nullptr;}; auto next_lambda=[](){ return 1; }; cout << sizeof lambda << endl; // auto lambda_size = sizeof [](){return nullptr;}; // Does not compile with it's own error, as promised auto plambda = &next_lambda; void *pointer= plambda; int *clambda ; clambda = (int*)pointer; cout << *clambda << endl; return 0; } It compiles fine, when ran it either outputs 1\n0\n (Solaris Studio 12.4 Sparc, 32-bit target) or dumps core with Bus error (memory alignment) (gcc and 64-bit SUNWspro 12.4) - IMGO more appropriate response - when dereferencing clambda. So basically, lambda is 1-byte memory location containing a zero (always a zero, in practice). For some reason, I was expecting something resembling a vtable. Does this mean that lambda semantics and implementation are something purely compile-time and thin ? "Victor Bazarov" wrote in message news:lvfpbr$a4j$1@dont-email.me... On 9/18/2014 4:39 PM, AP wrote: > return 0; > } > Is it wrong to read the open-std papers ? In your code 'lambda' is an object, the lambda-expression is the expression between the '=' and the semicolon that ends the declaration statement. What you're not supposed to do is to write .... sizeof []() { return nullptr; } ^^^^^^^^^^^^^^^^^^^^^^^^^ That is a lambda-expression. It cannot appear as an argument of 'sizeof'. It's pretty much useless there, if you ask me... V -- I do not respond to top-posted replies, please don't ask --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| Paavo Helde <myfirstname@osa.pri.ee>: Sep 19 12:33AM -0500 "AP" <unixpronospam@verizon.net> wrote in > You are right. But then, what's the meaning of sizeof lambda ? 1-byte The meaning of sizeof is defined as the spacing of elements if you put them in a (C-style) array. One must be able to tell different objects apart (there is another rule that says that all objects of the same type must have different addresses), so it cannot be never 0, even if the object is something like an empty struct which does not contain any content. > (always a zero, in practice). For some reason, I was expecting > something resembling a vtable. Does this mean that lambda semantics > and implementation are something purely compile-time and thin ? Yes, AFAIK lambdas are a compile-time thing. The function encapsulated in lambda is fully known at compile time, so by the zero overhead principle of C++ something like a vtable or a function pointer should not be needed. Redirection through a function pointer would mean potentially large runtime penalties when used in a tight loop. hth Paavo |
| Paavo Helde <myfirstname@osa.pri.ee>: Sep 19 12:35AM -0500 "AP" <unixpronospam@verizon.net> wrote in > WARNING - pure hypotheticals, may be waste of time unless you're PS. Please learn to quote. You will not receive a reply from Victor for example, because you top-posted. Cheers Paavo |
| David Brown <david.brown@hesbynett.no>: Sep 19 10:06AM +0200 On 19/09/14 05:40, AP wrote: > a zero, in practice). For some reason, I was expecting something > resembling a vtable. Does this mean that lambda semantics and > implementation are something purely compile-time and thin ? Basically, a lambda expression is just like a normal function with restricted scope and some "magic" to handle captures (i.e., invisible parameters are made and initialised to get data into and out of the lambda). It makes no more sense to use "sizeof" on a lambda expression than it would to apply it to the body of a function - but since the syntax first allowed "sizeof [](){return nullptr;}", such meaningless expressions had to be explicitly disallowed. You can use "sizeof" on "lambda" or "next_lambda" above - but it won't give you much useful information. It is up to the implementation to decide what it encodes with the "lambda" object - it could be a pointer to the compiled function, or an index in a table, or an internal number used to track code generation. It is quite possible that it contains nothing at all - but its "sizeof" is returned as 1 because that is the minimum allowed (to ensure that every object can have a unique address). With your construction above, you are trying to access this somewhat artificial object as an integer - this is definitely undefined behaviour, and will never give anything useful. |
| Juha Nieminen <nospam@thanks.invalid>: Sep 19 07:14AM > But listening experts they always say that we should not use the old C > array but rather vector. So why String is not done like: How exactly do you think std::string is internally implemented? If you say "with a std::vector?" then how exactly do you think std::vector is internally implemented? Do you see how this would result in a vicious cycle? There's nothing wrong in using raw pointers encapsulated within a class, as long as you know how to use them and follow good practices to avoid the mistakes and dangers inherent to them. They allow fine-tuning the behavior of your class. Note, however, that if std::vector (or other similar ready-made containers) are enough for your purposes (in terms of functionality and efficiency), then you should definitely use them because they make your code simpler and safer. --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| 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