- Boost-users - lists.preview.boost.org

A tip from the Dr.
by jackthompson99 23 Jan '02

23 Jan '02

Hey guys, I sent an e-mail to Dr. Stroustrup a couple nights ago, and he replied, "Have a look at boost.org. They exist specifically to provide better libraries in the context of the C++ standard library and to act as a test bed for new library ideas". So, here I am. I've installed and built my boost libraries, and I'm trying to figure out how to dig in. Anyway, here's what I was telling the Dr. I've been using C for about a decade, and C++ for about 7 yrs. I'm a huge fan of your invention, and I honestly feel like your name should eventually be as well known as Tesla and Edison. And the Standard Template Library is an incredibly well engineered system. I have a way to use it that is generic enough that it may be a candidate to be another standard. I know that's a lot to say. I'd like to explain it briefly, but first I should explain why I find it useful. Since I started working with assembler, I've always felt like the language I was using was missing something. I've used an assortment of languages, and it seems like they are all missing the same thing. The main part isn't really missing from C++, it's just not commonly understood. The concept of virtual construction is the core of the issue. Now I know that this problem is solved, but it really could stand for just one more thing to wrap it up into something usable for any ordinary C++ developer. Using a virtual constructor by way of a template, a developer can easily create any kind of object based on any type of identifier, but what good is that when the developer has exhausted all of his efforts on just building a simple system to dynamically create objects. The developer needs a way to organize these objects, without building another data warehouse. And I have never heard of a complicated database that shouldn't be fully hierarchical. So, the system should be one hundred percent re-entrant. Well, I have such a beast. I'm not done with it yet. I'm just now finishing up a project for Textron, where some of this concept was cultivated into my skill set. I am having a rough time explaining the system to my boss, and I'm in a real bind, but that's another story. The main thing that I've learned from this job is that the world needs to come together on one simple international standard for dealing with data and persistent C++ objects. I've used my ClassFactory / DataStore system as a foundation for another library that I call the WinFactory. This system simply uses the ClassFactory / DataStore as a database manager. The objects held in the database are simply graphical user interface components. This worked out really well, `till by boss took it apart. But I have a version of it that I'm re-writing at home that is much better. The database can be held either in a simple text format, resembling hypertext, or a binary file. The system relies heavily on the memory manager, so fast memory allocation is required. I have also populated an MFC user interface with data held in these objects. The system seems to be able to flex with just about anything, and I feel like it could at least contribute to discussions about new standards that are based on your standards. By the way, I need to find a team that I can work with who has good work ethics and integrity. Suggestions would be much appreciated. ..... So, I've looked at the library list in Boost, and haven't recognized anything like what I've built. I would love to explain this system. But, again, this one belongs to Textron, and all of the documentation too. I need to find some time to build this system for Boost.org. The main concept behind the system is a warehouse environment. The warehouse hase isles of goods. Each isle is any length, and each isle contains exactly one type of product. And every product contains a single pointer which is initally NULL. This makes it so that when you pull the product off the shelf and open it, you will see whatever the product is ( characters, integers, strings, etc. ), and you will find one more thing. It's called the nest. Now, until you try to use the nest, it's empty (NULL). But when you need it, it is created. What is this nest you ask? It's another warehouse. Just like the one that it is contained within. So, the entier concept is one hundred percent re-entrant. This makes it easy to build hierarchical infrastructures. The objects can be virtually any C++ thing. They persist with the greatest of ease to simple IO objects. User interfaces are easy to build with this system. Content editors view it as a script. C++ programmers view the script as C++ objects. Again, I need to finish re-writing the system, and I need to document it. But I feel like it is a candidate to become another Boost library. What do you think?????

2 1

RE: [Boost-Users] Subject: Poll results for Boost-Users
by Jim.Hyslop 23 Jan '02

23 Jan '02

Chris Little [SMTP:clittle@renlearn.ca] wrote: > When the question first came up of allowing members to view the membership > list, one of the moderators started a poll (around the beginning of > January). That'd be me. > Unfortunately polling in this group is limited to moderators. > The moderators then decided to discuss the issue amongst themselves and they > haven't reported back. Hoo, boy, I seem to have dropped the ball on several counts here. First, my apologies for not cancelling the poll after discovering polling was limited to moderators. Second, my apologies for not reporting back to the group on the results of our discussion (I'm taking responsibility for this, since I'm the one who opened the can of worms in the first place). We identified a potential problem with spam email harvesting. Granted, in the public pages emails are hidden, so that only the first letter of the domain appears (my address, for example, would appear as "jim.hyslop@l..." One of the moderators pointed out: > About half of the email addresses on > the first page start with either an a, h, or y. > ... the problem is that when harvesting email addresses you > don't need 100% accuracy. Just assume that a's are aol, all b's are > bigfoot, all e's are earthlink, all h's are hotmail.com, and all y's > are yahoo.com. These letters are going to be [greater than] half the list and you > will be correct [greater than] half the time. We could not come up with any compelling arguments in favour of opening the list. I believe the best summary was: > I'm not sure what the benefits of public membership would be. > Arguments such as "I need to know if X is a member of > the group" seem empty - this is a *mailing list* after all. > To access individuals, you should get hold of them in > other ways. If they are active members of the list, you'll > still know they're members. No moderators actually spoke out in favour of opening the list up, so the status quo remains. We moderators are, of course, open to suggestions, and if a reasonably strong argument comes up, then we will re-examine the issue. If anyone feels strongly about it, you can either post your rationale here or email the moderators at boost-users-owner(a)yahoogroups.com (the 'boost-users-owner' name is a bit misleading - email goes to all moderators, not just to the owner). Similarly, on the topic of polls themselves, the general consensus was that if or when we identify a good reason to run a poll, then we will open up the feature. Until then, there's no reason to change the status quo. -- Jim

1 0

RE: [Boost-Users] Subject: Poll results for Boost-Users
by Chris Little 23 Jan '02

23 Jan '02

When the question first came up of allowing members to view the membership list, one of the moderators started a poll (around the beginning of January). Unfortunately polling in this group is limited to moderators. The moderators then decided to discuss the issue amongst themselves and they haven't reported back. Chris > -----Original Message----- > From: James Curran/MVP [mailto:jamescurran@mvps.org] > Sent: Wednesday, January 23, 2002 8:29 AM > To: Boost-Users(a)yahoogroups.com > Subject: RE: [Boost-Users] Subject: Poll results for Boost-Users > > > How long was that poll open for? > > Truth, > James Curran > > > -----Original Message----- > From: Boost-Users(a)yahoogroups.com > [mailto:Boost-Users@yahoogroups.com] > Subject: Poll results > for Boost-Users > > > The following Boost-Users poll is now closed. Here are the > final results: > > > CHOICES AND RESULTS > - I want only the moderators to be able to view the > membership list, 0 votes, 0.00% > - I want anyone to be able to view the membership list, 0 > votes, 0.00% > [Non-text portions of this message have been removed]

1 0

RE: [Boost-Users] Subject: Poll results for Boost-Users
by James Curran/MVP 23 Jan '02

23 Jan '02

How long was that poll open for? Truth, James Curran -----Original Message----- From: Boost-Users(a)yahoogroups.com [mailto:Boost-Users@yahoogroups.com] Subject: Poll results for Boost-Users The following Boost-Users poll is now closed. Here are the final results: CHOICES AND RESULTS - I want only the moderators to be able to view the membership list, 0 votes, 0.00% - I want anyone to be able to view the membership list, 0 votes, 0.00%

1 0

Ann: Forward lookahead asserts now supported by regex lib
by John Maddock 23 Jan '02

23 Jan '02

The regex lib, now has experimental support for perl style forward lookahead assertions, using the syntax extensions: (?=exp) positive zero width forward assertion on exp. (?!exp) negative zero width forward assertion on exp. I'm currently looking for anyone willing to test these, and for real world test cases to add to the regression tests, before documenting the extensions and making them "official". Many thanks. - John Maddock http://ourworld.compuserve.com/homepages/john_maddock/

1 0

error with thread.hpp
by thrashmodule 19 Jan '02

19 Jan '02

I got this message: c:\boost_1_26_0\boost\thread\thread.hpp(17) : fatal error C1189: #error : Thread support is unavailable! I use VC++ on Win98 so now what??????????

2 1

Class destructor invocation - possible by hand?
by Jonathan Brownell 19 Jan '02

19 Jan '02

I have a question for all you C++ gurus. I'm writing a class that I would like to use the following technique in, and I'm not sure if it's portable or even legal, although VC++6 and VC++.NET, which I'm compiling in, work beautifully with it. Consider the following class, a very simplified example that I wrote to demonstrate: class House { public: explicit House(const int rooms) : m_rooms(rooms) { } ~House() { } private: const int m_rooms; }; Pretty straightforward. I'd like m_rooms to remain const to protect it from accidental modification by member functions, since it will *never* be changed during operation. Now, the first problem that arises is that this is illegal: House housingComplex[100]; Because, obviously, the constructor requires that the number of rooms be passed to it. (Yes, we could create it as an array of House pointers and create them dynamically, but in my case that will require inconveniences by everybody using my class.) So, we make it a default parameter and add an assignment operator: class House { public: explicit House(const int rooms = -1) : m_rooms(rooms) { } ~House() { } House& operator =(const House& source); private: const int m_rooms; }; When rooms == -1, the House is considered to be uninitialized. Now, we can do the following: House housingComplex[100]; housingComplex[0] = House(5); housingComplex[1] = House(4); (etc) The question is, how to implement the assignment operator? This is my method: House& House::operator =(const House& source) { assert(m_rooms == -1); this->~House(); new(this) House(source); return *this; } Yikes! I know this looks weird. First, assert verifies in debug mode that the object is in its uninitialized state. Then, the destructor is called manually to destruct the class and its contents. (In the actual class I'm working on, there are numerous member variables that must be appropriately destructed, and all of them are - I've checked.) Simply calling ~House(); will not compile, because the compiler assumes I'm trying to use the ~ operator illegally, so I have to call it through the 'this' pointer. Then, the placement new operator is used to create a new House in exactly the same space in memory as the old one, using the default copy constructor so that all the const variables are (re)initialized. Finally, a technicality for all assignment operators, a reference to the object is returned. (This is so C-style expressions like "var1 = var2 = var3 = 5;" can be used.) Now, this works beautifully on my VC++. But... is it legal C++?? Am I entering the realm of "undefined behavior", or is this a perfectly legitimate technique? Is there an obviously better solution to my problem? Are there caveats that I should be looking out for? Please, someone with more knowledge of the C++ standards, give me a hand here. Thanks! -Jonathan

6 6

RE: [Boost-Users] Class destructor invocation - possible by hand ?
by Tom Matelich 17 Jan '02

17 Jan '02

> > > > Also, I would recommend that you either reconsider > > > having the constant member variable, or use a > > > vector<>. > > > > Using a vector<T> won't work in this case, because the STL uses > > T::operator = in order to copy vector contents into new > locations during > > memory reallocation. And there's no logical way to > implement operator = > > when a const data member is present, which is the cause of this > > conversation. > > I could use std::list, since it doesn't do reallocation, but clients > > using this class in containers will most likely need random access > > iterators. > > > > Any other ideas? > > Easy option: Use a vector<shared_ptr<T> >. This will give you > basically > the behavior you want, with the ability to initialize the elements > directly. The drawback is that the data will be dynamically allocated. Another drawback is the interface is now pointers, not references. If you don't mind the dynamic allocation, the vector<shared_ptr<T> > can be contained by another class, overloading operator[], etc. The Boost Iterator Adapter library works very nicely for providing vector<T>::iterator behavior from a vector<shared_ptr<T> >::iterator. I can send you our vector-like class which uses adapted iterators if you would like. Re: the moderation. Yes, this is not a boost question, but it is a question boost can provide good solutions for, so where do you draw the line?

1 0

regex_match doesn't match in an embedded string
by soleani 17 Jan '02

17 Jan '02

Hi there, not sure how I could write that Subject line. Sorry :-) Here's the thing, I have a file with the following: KEY1 = ${short_localhost} KEY2 = bbbf<control2.cfg:OTHER_SECTION:${long_localhost}>aaaf:<he I need to extract the value between the {} when it starts with a $. My expression works ok for KEY1 (the value part, the string to the right of the equal sign), however it doesn't match for the value for KEY2. This is what I have: static const boost::regex expression( "\\$\\{(.*?)\\}" ); boost::cmatch what; if ( boost::regex_match( input, what, expression ) ) { cerr << "GOT IT!" << endl; } else { cerr << "NOPE" << endl; } where input is a std::string with the value described above. Why does it work for KEY1 and not KEY2? Interestingly enough, if I do the following: KEY1 = dd${short_localhost} it doesn't match either. This same expression in Perl works fine though. thanks, -Anibal

2 1

RE: [Boost-Users] boost tokenizer
by Jim.Hyslop 17 Jan '02

17 Jan '02

Peter Dimov [SMTP:pdimov@mmltd.net] wrote: > From: "hicks" <hicks(a)kgk.co.jp> > > Do you know why the compiler places precedence on that interpretation, > > rather than on one giving an instatiation of a local variable? > > The C++ standard says that a function declaration takes precedence. Don't > ask me why. :-) (At the risk of sliding seriously off topic...) I suspect it's something along these lines. Given this function: void f() { int WhatIsThis(); } Is "WhatIsThis" intended to be a declaration of a function, or is it intended to be a definition and default-initialization of an int variable? A C++ compiler cannot know, so the C++Standards committee had several choices: 1) require the compiler to flag the statement as an ambiguous statement 2) require the compiler to interpret the statement as a declaration of a function 3) require the compiler to interpret the statement as a definition of an int If we examine the same syntax in C, there is no question what it is: 'WhatIsThis' is a declaration of a function. That effectively eliminates #3 from consideration because you don't want one statement to have different meanings in C and in C++. I suspect the Committee then either flipped a coin (or some used other democratic means, such as debating and voting on the issue, thumb-wrestling, or playing paper-rock-scissors) to decide between #1 and #2, or choose to adapt the well-worn guideline "When in doubt, do as the ints do" to "When in doubt, do as C does". -- Jim

1 0