- Strange error - 1 Update
- C++ needs some help - 1 Update
- "Bjarne Stroustrup announces C++ Core Guidelines" - 5 Updates
- Why is a virtual desconstructor called when a derived class object created? - 4 Updates
| Anand Hariharan <mailto.anand.hariharan@gmail.com>: Oct 05 03:59PM -0700 On Thursday, September 24, 2015 at 4:00:37 PM UTC-5, jacobnavia wrote: > > The error is coming from some part of CFowardBlock that you left out. It > > probably has a pure virtual function and was made to be derived from. > It has many virtual functions, yes. Presumably, one or more of those virtual member functions have "= 0;" at the end of their declarations? That is what makes CForwardBlock 'abstract' (i.e., it cannot be instantiated on its own). - Anand |
| woodbrian77@gmail.com: Oct 05 03:40PM -0700 Is there a growing sense that on line code generation is to software what the wheel was to transportation? I've been watching the latest serialization questions on Stackoverflow for the past month or so. http://stackoverflow.com/search?page=1&tab=newest&q=serialization It looks like Java and C# are the two most popular languages when it comes to that search. I believe C++ has some advantages over those languages, but their support for reflection has also given them an advantage over C++ in this area. The C++ Middleware Writer (CMW) is my effort to eliminate the advantage those languages have when it comes to serialization. I'm interested in helping those who are willing to use the CMW in their projects. For more details see this page -- http://webEbenezer.net/about.html . If you like using C++ and would like to help it become even more competitive than it already is, I hope you will consider becoming an early adopter of this approach. There are still some tier-1 user IDs available. These IDs are the equivalent of handy domain names like bikes.com, wnd.com, etc. I think these IDs will be increasingly valuable because they only 1 byte needs to be processed for the ID in code generation requests, thereby giving tier-1 users an advantage over those who are slower to start using the CMW. Brian Ebenezer Enterprises - So far G-d has helped us. http://webEbenezer.net |
| "Öö Tiib" <ootiib@hot.ee>: Oct 04 11:33PM -0700 On Sunday, 4 October 2015 10:04:00 UTC+3, Chris Vine wrote: > to be used by other modules which ought to be documented), then the > interest group for the hypothetical header file containing class > definitions comprises the authors and maintainers of the code. C++ does not contain modules. "Modules" are usually just some sort of group of classes. In C++ programs there are sometimes hundreds of classes. Most of those classes do not participate in interface of "module". > order for the maintainer to maintain (and so understand) any given > class method, she needs to look at the data that the class is operating > on. It perhaps depends if you get work that your "class Foo needs maintenance" or do you get work that "your program acts oddly / non-suitably". > something best done by declaring the class data before declaring the > public methods. I see zero advantage in declaring the public methods > in advance of the data, as proposed in the style guide. "Methods"? Smells like Java here. |
| Daniel <danielaparker@gmail.com>: Oct 05 06:05AM -0700 On Monday, October 5, 2015 at 2:34:15 AM UTC-4, Öö Tiib wrote: > C++ does not contain modules. If Herb Sutter and Andrei Alexandrescu are allowed to use "modules" in a looser sense ("Don't allow exceptions to propagate across module boundaries"), I don't see why Chris can't. > In C++ programs there are sometimes hundreds of > classes. Most of those classes do not participate in interface > of "module". Indeed. > > on. > It perhaps depends if you get work that your "class Foo needs maintenance" > or do you get work that "your program acts oddly / non-suitably". Unclear. Generally, the maintainer has to understand the implementation. > > I see zero advantage in declaring the public methods > > in advance of the data. > "Methods"? Smells like Java here. Not to mention C#, Python, Javascript, D, and C++ (where it's a synonym for member function) ... Daniel |
| "Öö Tiib" <ootiib@hot.ee>: Oct 05 08:39AM -0700 On Monday, 5 October 2015 16:06:17 UTC+3, Daniel wrote: > On Monday, October 5, 2015 at 2:34:15 AM UTC-4, Öö Tiib wrote: > > C++ does not contain modules. > If Herb Sutter and Andrei Alexandrescu are allowed to use "modules" in a looser sense ("Don't allow exceptions to propagate across module boundaries"), I don't see why Chris can't. ad verecundiam? Book author typically explains what they mean with a word. Without explaining a "module" is just "some sort of group of classes" in C++. I already explained it but you snipped that. > > classes. Most of those classes do not participate in interface > > of "module". > Indeed. The documentation however is about interface of "module" (whatever it means in particular context). > > It perhaps depends if you get work that your "class Foo needs maintenance" > > or do you get work that "your program acts oddly / non-suitably". > Unclear. Defect reports or feature requests that concern classes are only about libraries. Most C++ code are not such libraries. On most cases the defect reports or feature requests are about behavior of particular programs. > Generally, the maintainer has to understand the implementation. Maintainer has first to understand what the classes are supposed to do. That is easier when public interface is put first. Implementation details are of interest only when it is clear that a class does not do what it is supposed to do. > > > in advance of the data. > > "Methods"? Smells like Java here. > Not to mention C#, Python, Javascript, D, and C++ (where it's a synonym for member function) ... Especially weird is to read "template methods" like Chris wrote. "Template method" is name of behavioral design pattern and has nothing to do with "member function templates" of C++. Of course anyone can write how and what they want and mean whatever they think with it. Messy classes and incomprehensible documentation. Actual reality. |
| "Tobias Müller" <troplin@bluewin.ch>: Oct 05 04:21PM > better to have data first. And generally, I find it better to declare > things before they're used. That's recognized as a sound rule in almost > every other context, and it doesn't cease to be a good idea in C++. That's why classes/enums are declared first. But in C++ usually you don't _use_ data members in the class definition. Except possibly for inline functions, but I always put after the class definition. Tobi |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 05 07:00PM On Sun, 2015-10-04, Chris Vine wrote: >> After all, most code is not intended as reuable libraries. > I was responding to your comment that "I read the header file to see > the API". I do not do so: I look at the documentation to see the API. I was sloppy when I wrote both my postings -- sorry. > to be used by other modules which ought to be documented), then the > interest group for the hypothetical header file containing class > definitions comprises the authors and maintainers of the code. Yes -- and that was exactly the sitation I was thinking about. But when I'm modifying the code, of course I'm seeing APIs! I may be allowed to modify class Foo, but unless I find a problem with it I will treat it as something fixed. It's an API, but I'm allowed to read the implementation if I need to, and change the implementation or the interface if necessary (since I have control over all code using it, and can adjust it). That too looks silly now that I reread it ... because that's obviously how you use header files in C++, isn't it? Divide and conquer, and so on. That's what they are for /within/ a project. > In order for the maintainer to maintain (and so understand) any given > class method, she needs to look at the data that the class is operating > on. You need the /option/ to do so, but most of the time you want to deal with the interface only. I cannot keep all of the implementation details in my head at once ... /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| fl <rxjwg98@gmail.com>: Oct 04 04:53PM -0700 Hi, When I trace through a derived class object, it is found that the base class virtual de-constructor is called in the last step of the object creating code. Here is the base class: ........... class Item_base { public: virtual Item_base* clone() const { return new Item_base(*this); } public: Item_base(const std::string &book = "", double sales_price = 0.0): isbn(book), price(sales_price) { } std::string book() const { return isbn; } virtual double net_price(std::size_t n) const { return n * price; } // no work, but virtual destructor needed // if base pointer that points to a derived object is ever deleted virtual ~Item_base() { } private: std::string isbn; // identifier for the item protected: double price; // normal, undiscounted price }; Below is the derived class: class Sales_item { public: // default constructor: unbound handle Sales_item(): p(0), use(new std::size_t(1)) { } // attaches a handle to a copy of the Item_base object Sales_item(const Item_base&); // copy control members to manage the use count and pointers Sales_item(const Sales_item &i): p(i.p), use(i.use) { ++*use; } ~Sales_item() { decr_use(); } Sales_item& operator=(const Sales_item&); // member access operators const Item_base *operator->() const { return p; } const Item_base &operator*() const { return *p; } private: Item_base *p; // pointer to shared item std::size_t *use; // pointer to shared use count // called by both destructor and assignment operator to free pointers void decr_use() { if (--*use == 0) {delete p; delete use;} } }; The C++ code is: int main() { Sales_item item1(Item_base("123", 45)); What I see is that before jumps to the next line, item1 calls virtual ~Item_base() { } in the base class. What is the reason for this call? Thanks, |
| Ian Collins <ian-news@hotmail.com>: Oct 05 01:04PM +1300 fl wrote: > Hi, > When I trace through a derived class object, it is found that the base class > virtual de-constructor is called in the last step of the object creating code. "destructor" <snip> > int main() > { > Sales_item item1(Item_base("123", 45)); ^^^^^^^^^ > What I see is that before jumps to the next line, item1 calls > virtual ~Item_base() { } > in the base class. What is the reason for this call? You are creating a temporary Item_base object. -- Ian Collins |
| Ian Collins <ian-news@hotmail.com>: Oct 05 01:08PM +1300 fl wrote: > }; > Below is the derived class: > class Sales_item { By the way, what makes you call this a derived class? -- Ian Collins |
| fl <rxjwg98@gmail.com>: Oct 04 07:01PM -0700 On Sunday, October 4, 2015 at 8:08:56 PM UTC-4, Ian Collins wrote: > By the way, what makes you call this a derived class? > -- > Ian Collins Thanks Ian. Your two questions are the key to my problems. I just realized that it is not a derived class. Thus, it is a temporary class variable. I understand it now. |
| 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