- inheritance in C++ - 4 Updates
- Quick Newbie question - 4 Updates
- Quick Question - 7 Updates
- Networking and C++ question - 5 Updates
- Confused by C++ Primer's discusion of const_cast - 1 Update
- faster than c - 1 Update
- Polymorphism and std::copy - 3 Updates
| Victor Bazarov <v.bazarov@comcast.invalid>: Apr 27 11:57AM -0400 On 4/27/2015 11:36 AM, Stefan Ram wrote: > be called, while in the case of a virtual method, the method > in the derived class will be called. > Are there any other cases that I forgot? You can include a call to a virtual member from within a non-virtual member function as an additional test. Like void mv() { /* after own output */ this->v(); } It will likely give you the same result as calling 'v' from 'main', yet it demonstrates the whole point of polymorphism: while 'this' is statically typed, since it's a pointer, its utilization is polymorphic in nature. Another exercise I suggest is 'const' versus non-const member functions. Good luck! V -- I do not respond to top-posted replies, please don't ask |
| Paavo Helde <myfirstname@osa.pri.ee>: Apr 27 11:48AM -0500 ram@zedat.fu-berlin.de (Stefan Ram) wrote in > ::d.s(); std::cout << "calling non-static via derived > ::instance\n"s; d.m(); std::cout << "calling virtual via > ::derived instance\n"s; d.v(); } You can also call virtual method non-virtually: d.base::v(); |
| Luca Risolia <luca.risolia@linux-projects.org>: Apr 27 10:38PM +0200 Il 27/04/2015 17:36, Stefan Ram ha scritto: > using namespace ::std::literals; What do you keep prepending std:: with all those pedantic ::? |
| Luca Risolia <luca.risolia@linux-projects.org>: Apr 27 10:39PM +0200 > What do you keep prepending std:: with all those pedantic ::? *Why |
| Doug Mika <dougmmika@gmail.com>: Apr 27 12:55PM -0700 I am learning to properly read the www.cplusplus.com reference material to quickly decipher what it says, and I have come upon the following: the std::list class has a sort member function that comes in two overloaded forms. The first is: void sort(); which easily enough says that for any instance of a list you can invoke the sort() member function. The problem I have, is how do I read the second overloaded form of sort: template <class Compare> void sort (Compare comp); I know the basics of templates, in particular that these can be used to define template functions and template classes, but I have never heard of class member functions themselves being template member functions. Basically, looking at this second overloaded form of sort, how would I know that this sort takes a predicate or a function (ie how should I know that Compare is a function or I guess a functor?) Thanks |
| Paavo Helde <myfirstname@osa.pri.ee>: Apr 27 03:13PM -0500 Doug Mika <dougmmika@gmail.com> wrote in > functions. Basically, looking at this second overloaded form of sort, > how would I know that this sort takes a predicate or a function (ie > how should I know that Compare is a function or I guess a functor?) By reading the documentation. On the http://www.cplusplus.com/reference/list/list/sort/?kw=list%3A%3Asort page it says for example: comp: Binary predicate [...] This shall be a function pointer or a function object. And there is also a relevant example included. There is a long-developed C++ feature ("concepts") which would formalize such requirements, but doing this properly has proved to be tricky and this feature is not yet standardized. hth Paavo |
| Doug Mika <dougmmika@gmail.com>: Apr 27 01:28PM -0700 ok, but why does a class member function have template<class Compare> in front of it? What does this represent? What does it indicate in the instance of std::list.sort(comp)? On Monday, April 27, 2015 at 2:55:26 PM UTC-5, Doug Mika wrote: |
| Barry Schwarz <schwarzb@dqel.com>: Apr 27 01:34PM -0700 On Mon, 27 Apr 2015 12:55:13 -0700 (PDT), Doug Mika >but I have never heard of class member functions themselves being template member functions. Basically, looking at >this second overloaded form of sort, how would I know that this sort takes a predicate or a function (ie how should >I know that Compare is a function or I guess a functor?) Didn't the example further down the web page make it clear.? To be consistent, you read the first form as "sort the elements of the list using the default operator< that may be defined for the element type as the comparison function." If the list contains strings, then it would use the operator< defined for the string class. If the list contains int, then it would use the < operator defined for int. If the list contains struct, it should generate a diagnostic that there is not default operator< defined for struct. Read the second as "sort the elements of the list using the specified function as the comparison function." It is your job to insure the specified function exists, takes the correct argument types, and returns either 0 or 1 depending on the result of the comparison. -- Remove del for email |
| ram@zedat.fu-berlin.de (Stefan Ram): Apr 20 04:49PM >The official definition of cin.get(cStr, n) is as follows: >std::istream::get >istream& get (char* s, streamsize n); That's a declaration, not a definition. >char someString[256]; >cin.get(someString, 255); >we ignore the return type istream&? You use the expression statement in the second line of the typed code given. This is the most fundamental statement in C++ taught at the beginning of beginner courses. The return type of »get« is not even consciously ignored in this case, it just doesn't matter. >What purpose does this return type serve? I assume that the return value is the target object. In this case, it would allow one to write cin.get( s, 255 ).get( s1, 255 ); . |
| ram@zedat.fu-berlin.de (Stefan Ram): Apr 21 04:35PM >. This copies the argument initializer list to the parameter il, >but if the underlying array has static storage duration, >then the pointer will /not/ dangle, indeed. I think it's crucial whether the »underlying array« of an initializer list is a part of the initializer list or is referenced by the initializer list. When it is /referenced/ by the initializer list, the parameter will refer the same underlying array as the argument, and when this array has static storage duration, a pointer into it will not dangle. |
| ram@zedat.fu-berlin.de (Stefan Ram): Apr 19 04:39AM Newsgroups: comp.lang.c,comp.lang.c++ >Again, this would be problematic in C++, unless the object is const. So >one could have: >const int* y = std::begin({ 1, 2, 3 }); What is this? { 1, 2, 3 } seems to be used to initialize a temporary object whose lifetimes ends at the semicolon, so the pointer y then would be dangling? |
| ram@zedat.fu-berlin.de (Stefan Ram): Apr 20 04:44PM >Subject: Quick Question You should use more specific subject lines in Usenet. |
| ram@zedat.fu-berlin.de (Stefan Ram): Apr 27 03:36PM I have not yet learned a lot about inheritance in C++. So, I tried to make up a program to »test all cases that can possibly happen". You can see this program and its output below. #include <iostream> #include <ostream> #include <string> #include <memory> using namespace ::std::literals; struct base { static void s(){ ::std::cout << "base s\n"s; } void m(){ ::std::cout << "base m\n"s; } virtual void v(){ ::std::cout << "base v\n"s; }}; struct derived : base { static void s(){ ::std::cout << "derived s\n"s; } void m(){ ::std::cout << "derived m\n"s; } virtual void v(){ ::std::cout << "derived v\n"s; }}; int main() { { ::base b; ::std::cout << "calling static via base instance\n"s; b.s(); ::std::cout << "calling non-static via base instance\n"s; b.m(); ::std::cout << "calling virtual via base instance\n"s; b.v(); } { ::derived d; ::std::cout << "calling static via derived instance\n"s; d.s(); ::std::cout << "calling non-static via derived instance\n"s; d.m(); ::std::cout << "calling virtual via derived instance\n"s; d.v(); } { ::std::unique_ptr< ::base >bd = ::std::make_unique< ::derived >(); ::std::cout << "calling static via base pointer to derived\n"s; bd->s(); ::std::cout << "calling non-static via base pointer to derived\n"s; bd->m(); ::std::cout << "calling virtual via base pointer to derived\n"s; bd->v(); } { ::std::unique_ptr< ::derived >dd = ::std::make_unique< ::derived >(); ::std::cout << "calling static via derived pointer to derived\n"s; dd->s(); ::std::cout << "calling non-static via derived pointer to derived\n"s; dd->m(); ::std::cout << "calling virtual via derived pointer to derived\n"s; dd->v(); }} calling static via base instance base s calling non-static via base instance base m calling virtual via base instance base v calling static via derived instance derived s calling non-static via derived instance derived m calling virtual via derived instance derived v calling static via base pointer to derived base s calling non-static via base pointer to derived base m calling virtual via base pointer to derived derived v calling static via derived pointer to derived derived s calling non-static via derived pointer to derived derived m calling virtual via derived pointer to derived derived v It seems that there are only four lines that are really remarkable, viz., calling non-static via base pointer to derived base m calling virtual via base pointer to derived derived v That is, when you call a non-virtual method via a pointer of type »base« that points to an instance of the class »derived«, the method declared in the base class will still be called, while in the case of a virtual method, the method in the derived class will be called. Are there any other cases that I forgot? |
| ram@zedat.fu-berlin.de (Stefan Ram): Apr 27 04:05PM >Good luck! Thank you! In the meantime, I also became aware that I might add the case of a /reference/ of base type referencing an instance of a derived type (while I assume that it will behave in correspondence to a /pointer/ of base type pointing to an instance of a derived type.) |
| ram@zedat.fu-berlin.de (Stefan Ram): Apr 27 08:05PM Someone asked using an inappropriate subject line: >how should I know that Compare is a function or I guess a functor? »Compare« is a concept that is being described on http://en.cppreference.com/w/cpp/concept/Compare . (Maybe you are still using the old C++14? C++14 did not have concepts. But we are living in 2015 now!) |
| scott@slp53.sl.home (Scott Lurndal): Apr 27 01:29PM >http://stackoverflow.com/questions/29882666/c-socket-programming-read-write >Is limiting the size of the read the problem as EJP suggests? >I was thinking it might have to do with the OP's assuming int is 4 bytes. Don't see how this has anything to do with C++. One must first understand the nature of TCP (stream, not packet) and interactions with blocking (or non-blocking) behavior. >I have a C++ library that helps with transferring files between >clients and server -- <blatent advert omitted> Ah, never mind. You're advertising your product. Shame on you. |
| woodbrian77@gmail.com: Apr 27 08:06AM -0700 On Monday, April 27, 2015 at 8:29:26 AM UTC-5, Scott Lurndal wrote: > Don't see how this has anything to do with C++. One must > first understand the nature of TCP (stream, not packet) and > interactions with blocking (or non-blocking) behavior. It may not be using a lot of new features, but it's C++. > Ah, never mind. You're advertising your product. Shame on you. G-d bless you. Brian Ebenezer Enterprises - "But realize this, that in the last days difficult times will come. For men will be lovers of self, lovers of money, boastful, arrogant, revilers, disobedient to parents, ungrateful, unholy, unloving, irreconcilable, malicious gossips, without self-control, brutal, haters of good" 2nd Timothy 3:2 http://webEbenezer.net |
| drew@furrfu.invalid (Drew Lawson): Apr 27 03:28PM In article <888a30f1-b148-4b1f-86f8-a40f4b8a3a09@googlegroups.com> >http://stackoverflow.com/questions/29882666/c-socket-programming-read-write >Is limiting the size of the read the problem as EJP suggests? >I was thinking it might have to do with the OP's assuming int is 4 bytes. I use a similar protocol for messaging, but I specify the size as uint32_t and normalize it with htonl()/ntohl(). I didn't read through the loops carefully. No comments combined with single-letter variable names makes my brain bleed. Were I debugging that, I'd compare the received file with the original. That would suggest what the problem is. (Well, I'd also split stuff out into sendMessage() and receiveMessage() or such.) -- Drew Lawson I only came in search of answers, never planned to sell my soul I only came in search of something left that I could call my own |
| scott@slp53.sl.home (Scott Lurndal): Apr 27 05:03PM >> first understand the nature of TCP (stream, not packet) and >> interactions with blocking (or non-blocking) behavior. >It may not be using a lot of new features, but it's C++. The problem being discussed in the example you posted is related to network protocols, specifically to TCP, more specifically regarding the misconception that some programmers have about the preservation of message boundaries in a stream-based protocol and how IO_NONBLOCK changes the behavior of system calls accessing the stream. The fact that the example was written in C++ is unrelated to the problem being discussed. The write answer, is to use sendfile(2) :-). |
| woodbrian77@gmail.com: Apr 27 12:34PM -0700 On Monday, April 27, 2015 at 12:03:59 PM UTC-5, Scott Lurndal wrote: > The write answer, is to use sendfile(2) :-). I entered "sendfile compression" without the quotes into https://duckduckgo.com and it came back with: "Did you mean send file compression?" It put a space between send and file. And when I search the sendfile man page for compression, I get "Pattern not found." Compression is important for what I'm working on. Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net |
| Juha Nieminen <nospam@thanks.invalid>: Apr 27 07:38AM > char * p = const_cast<char*>(pc); // Ok but writing through p is undefined. > Why is writing through p undefined? I thought this was an archetypal use of const_cast -- create a non-const object from a low-level const object. > Why is this use of const_cast wrong? Because 'pc' may be pointing to something that literally can't be modified or, if it's modified, might break something. (String literals are a typical example: They might be unmodifiable depending on the compiler/architecture, or they might be modifiable but if you do, you'll break something, eg. if the compiler merges identical string literals, or if the literal resides in a segment of memory that can't be written to, in which case bad things usually happen.) --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| Ian Collins <ian-news@hotmail.com>: Apr 21 04:36PM +1200 Stefan Ram wrote: > the begin pointer of that array will be computed. The result > is a pointer to the begin of that array. Then, that array will > be destroyed. It is as if 18.9.3 Initializer list range access template<class E> const E* begin(initializer_list<E> il) noexcept; 1 Returns: il.begin(). > { array( ::std::initializer_list< int >const ){}; > ~array(){ ::std::cout << "I, temporary array, destroyed\n"; } }; > int * begin( array ){ return nullptr; } So this always returns nullptr. > int main() > { ::std::cout << "before\n"; > const int * y = begin( { 1, 2, 3 }); /* this is like your code */ So this is equivalent to y = nullptr; > I, temporary array, destroyed > after > y = 0 int main() { std::cout << "before\n"; const int * y = std::begin( { 1, 2, 3 }); /* this is like your code */ std::cout << "after\n"; std::cout << "y = " << y << '\n'; } before after y = 0x8051294 -- Ian Collins |
| legalize+jeeves@mail.xmission.com (Richard): Apr 21 03:29PM [Please do not mail me a copy of your followup] Luca Risolia <luca.risolia@linux-projects.org> spake the secret code >In this case: > vecOfFish.push_back(std::make_shared<Tuna>()); > vecOfFish.push_back(std::make_shared<Carp>()); Even better: if you just need a container of polymorphic objects use std::unique_ptr<T> and std::make_unique[*]. I see people over-usign shared_ptr when unique_ptr would suffice. [*] if your implementation doesn't yet have make_unique or unique_ptr, then consider using an alternative from boost. -- "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> |
| Luca Risolia <luca.risolia@linux-projects.org>: Apr 21 06:16PM +0200 On 21/04/2015 17:29, Richard wrote: >> vecOfFish.push_back(std::make_shared<Carp>()); > Even better: if you just need a container of polymorphic objects use > std::unique_ptr<T> and std::make_unique[*]. If it's better clearly depends on the real application. unique_ptr's are inadequate, if you need to copy the vector for some reasons. |
| Victor Bazarov <v.bazarov@comcast.invalid>: Apr 21 12:03AM -0400 On 4/20/2015 7:06 PM, Luca Risolia wrote: > In this case: > vecOfFish.push_back(std::make_shared<Tuna>()); > vecOfFish.push_back(std::make_shared<Carp>()); Given 'class Derived : public Base {};', is 'shared_ptr<Derived>' convertible to 'shared_ptr<Base>'? Your suggestion seems to imply as much... 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. |
No comments:
Post a Comment