- Boost - lists.boost.org

Re: [boost] Re: Logo substance. [was: Re: Logo... and page design.]
by JOAQUIN LOPEZ MU?Z 24 Nov '04

24 Nov '04

----- Mensaje original ----- De: David Abrahams <dave(a)boost-consulting.com> Fecha: Martes, Noviembre 23, 2004 11:25 pm Asunto: [boost] Re: Logo substance. [was: Re: Logo... and page design.] > Rich Johnson <rjohnson(a)dogstar-interactive.com> writes: > > >>> I find this one too static, compared to Dave's attempts. > >>> It does have the sense of solidity that some have asked for, > >>> but I'd rather have a more dynamic feel (which reflects, I think, > >>> more accurately what boost is. Much of boost is not for the > >>> faint-hearted.) > >> > >> Thanks. Actually I thought that Joaquín's design was plenty > dynamic>> and better than mine on simplicity grounds. I do agree > about the ring > >> and the ++. Put a little white gap between the rocket and the > ring at > >> the intersection, and you've got your "C." > >> > > Hmm... two little puffs of exhaust could be +'s and the third > could be > > a 'C'-ring. It's kinda' cartoony, but fun. > > Or you could make the +es into four-pointed stars. > Like this? (again, this can be implemented more carefully, it's just a sketch to explore the idea.) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

Re: [boost] Re: Re: Any interest in a boost::glob() function?
by Beman Dawes 23 Nov '04

23 Nov '04

At 03:16 PM 11/23/2004, Rich Johnson wrote: >Yup. This is getting further into hypothetical design than is probably >appropriate, but....assuming the FS provides an is_name_equivalent() >convenience function (which I think it should): > >A monolithic 'is_name_equivalent()' function that sets up and tears >down a regex each time it's invoked would have performance issues when >used in the context of the globber. > >A reusable 'name_comparator' object(functor) supplied by the FS layer >could be instantiated once as part of the glob_predicate. > >Of course this raises the issue of what happens when you glob across a >FS boundary(mount points and links)--must the name_comparator change >accordingly? On Windows, it is not possible to tell if two names (or paths) are equivalent just by looking at the name (or path). The question can only be answered by inspecting the current state of the filesystem. For example, if a directory contains both files "A" and "a", then these two names are not equivalent. But if the directory only contains a file named "A", then "a" is equivalent in that directory at the current time. Since you can't determine equivalence, if neither exist then the equivalent() function throws in that case. --Beman

1 0

RE: [boost] boost.thread : Can one create a thread with anobjectmember function?
by Tim Laplaca 23 Nov '04

23 Nov '04

I assume I need to include some bind includes to get this to compile (I'm getting "error: `bind' undeclared in namespace `boost'". I see several includes in /usr/include/boost/bind. Which should I include? None are obvious to me, like 'bind.hpp' would be. Thanks, Tim -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov Sent: Monday, November 22, 2004 5:57 PM To: boost(a)lists.boost.org Subject: Re: [boost] boost.thread : Can one create a thread with anobjectmember function? Tim Laplaca wrote: > boost::thread_group thrds; > > objclass * objthread; > > > > objthread = new objclass; > > thrds.create_thread( (objthread->p) ); Do this instead: boost::shared_ptr<objclass> objthread( new objclass ); thrds.create_thread( boost::bind( &objclass::dowork, objthread ) ); Even better, drop the objclass entirely and do this: void dowork( int tid, string valtwo ) { // do work } thrds.create_thread( boost::bind( dowork, my_thread_id, my_valtwo ) ); _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Re: [boost] Re: Another logo proposal
by JOAQUIN LOPEZ MU?Z 23 Nov '04

23 Nov '04

----- Mensaje original ----- De: "Aaron W. LaFramboise" <aaronrabiddog51(a)aaronwl.com> Fecha: Martes, Noviembre 23, 2004 9:21 pm Asunto: Re: [boost] Re: Another logo proposal > David Abrahams wrote: > > > With all due respect, I find this logo direction dry, unattractive, > > and not memorable. > > For contrast, I think Joaquín Muñoz's preferred black on white > plus-plus > design is the best I've seen so far, including his rockets. If > all of > the thus-far proposed logos were put before me in a controlled > test, and > the examiner asked me which one of these logos was most likely the > logoof a high-quality, industrial-grade, corporate-accepted software > package, I'd go with the plus-plus design. > Hey, good to know there's someone on my side :) thanks! My particular "++ in a block" proposal aside, I think it'd be good that an stylized, abstract logo be adopted, or at least a simple one, amenable to multiple rendering contexts (b/w, small size, etc.) Cartoon logos might look fun, but they can clash with the environment in many aspects (general tone, color palette, style.) In contrast, a stylized logo has the same connotational power without any of the aforementioned potential problems. Companies that invest big bucks in corporate image know it well. I propose you a simple exercise: name the first 20 companies that come to your mind, visit their websites and take a look at the logo. How many of them have a figurative icon? How many of them have a multicolor icon (say, more than 3 colors)? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: RE: [boost] Another logo proposal
by Robert Geiman 23 Nov '04

23 Nov '04

---- Original Message ---- From: joaquin(a)tid.es To: boost(a)lists.boost.org Subject: Re: RE: [boost] Another logo proposal Date: Tue, 23 Nov 2004 01:30:24 +0100 >> >> >I think this is what you've got in mind. >> >Myself, I don't like it much. Not so compact, and >> >the "C++" thing becomes too obvious. But well, this >> >is just my opinion, of course. >> >> Close, but not quite what I was thinking. The version you created >> goes below this bottom of the first +, which as you said makes it >> less compact. >> >> Take that bottom C part and puch it up one "block", making sure you >> keep the + sign on top of the background. In essence, you'd really >> just be adding a single block of background in the lower left gap >of >> the first +, and another block to the lower right gap of the first >+, >> if that makes any sense. >> > >Like this? That's it exactly. Although it's almost not obvious enough that there's a C there. Of course, in the inverted version you created, if the background C was a slightly different color than the ++ it would help it stand out a little more. - Robert Geiman

3 3

Logo design
by Miro Jurisic 23 Nov '04

23 Nov '04

I don't mean to put down anyone's effort, but some of the logo sketches were, well, terrible. I think that a number of people here have had interesting ideas in terms of what the logo might contain (whether it's a rocket or angle brackets), but very few of the resulting images were esthetically pleasing. My proposal is that we take a small set of possible ideas to someone with graphic design skills. I am not implying we have nobody like that here, I just think this is very quickly degenerating into a shed-painting discussion, and I think we can save everyone a lot of time by picking 1-3 ideas (e.g., "boost rocket") and having someone adept of converting ideas into images work with that. meeroh "I can't draw to save my life, and I know it" PS. I think a design which simply reads "boost" and has the letter t be the rocket would work well -- If this message helped you, consider buying an item from my wish list: <http://web.meeroh.org/wishlist>

8 13

[Review] Named Parameters library
by Thomas Witt 23 Nov '04

23 Nov '04

My vote for the Named Parameters library is a clear YES, but ... the documentation needs to be improved. - What is your evaluation of the design? I think the design is sound. It provides all the functionality I can think of. I particularly like lazy evaluation of defaults and controlling the overloadset. I am convinced that removing spurious overloads will become ever more important in modern C++. - What is your evaluation of the implementation? I did a very brief reading of the code. No complaints here. - What is your evaluation of the documentation? The documentation needs improvement. Ignoring a few typos in the current documentation I still think the documentation is not sufficient for using the library. A reference is needed. - What is your evaluation of the potential usefulness of the library? To me named parameters have the potential to significantly improve the interfaces used in C++ code, be it application code or library code. A problem that AFAICS every named parameter lib faces is the issue of keyword scoping. The keyword objects have the potential to reserve names in scopes that they shouldn't. I think the only way to find out how big this problem is in practice and what the best idioms for scoping the keywords are is by using named parameter libraries. The other issue is the tradeoff between ease of use/interface design and the associated compiletime and runtime costs. E.g. compile speed and codesize. Again I think we will only find out by experimenting. - Did you try to use the library? With what compiler? Did you have any problems? No. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? About 1.5h - Are you knowledgeable about the problem domain? No, as far as named parameter concepts outside C++ are concerned. Regards Thomas -- Thomas Witt witt(a)acm.org

2 2

RE: [boost] boost.thread : Can one create a thread with an objectmember function?
by Tim Laplaca 23 Nov '04

23 Nov '04

Thanks! Since I don't need the class anymore I don't need to use bind, but I'll keep this in mind for the future. Thanks again, Tim -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Cory Nelson Sent: Monday, November 22, 2004 5:58 PM To: boost(a)lists.boost.org Subject: Re: [boost] boost.thread : Can one create a thread with an objectmember function? Yup! boost::thread(boost::bind(&classname::method, boost::ref(thisptr))); On Mon, 22 Nov 2004 10:50:17 -0500, Tim Laplaca <tlaplaca(a)voiceglo.com> wrote: > I am very new to boost, I apologize if this has been asked before. I > searched the mailing list archive but could not find an answer to my > question. > > I was successful creating threads with functions that are not members of > objects, but when I try to create threads with a pointer to an object > member I get compilation errors (MS Visual Studio .NET). > > Examples: > > class objclass; > > typedef void (objclass::*pmf)(); // ptr to member func > > class objclass > > { > > public: > > objclass() : thread_id (0) { p=&objclass::dowork; } > > inline setthreadid(int x) {thread_id = x;} > > inline setvaltwo(std::string str) {valtwo = str;} > > void dowork(); > > pmf p; // pointer to dowork member function > > int getthreadid() {return thread_id;} > > std::string getvaltwo() {return valtwo;} > > private: > > int thread_id; > > std::string valtwo; > > }; > > void objclass::dowork() > > { > > } > > (In the main...) > > boost::thread_group thrds; > > objclass * objthread; > > objthread = new objclass; > > thrds.create_thread( (objthread->p) ); > > I get the following error: > > c:\Boost\include\boost-1_31\boost\function\function_template.hpp(427): > error C2664: 'void > boost::function0<R>::assign_to<Functor>(FunctionPtr,boost::detail::funct > ion::function_ptr_tag)' : cannot convert parameter 2 from > 'boost::detail::function::member_ptr_tag' to > 'boost::detail::function::function_ptr_tag' > > with > > [ > > R=void, > > Functor=pmf, > > FunctionPtr=pmf > > ] > > Is there a way around this problem, or is it simply not possible to make > threads from object members with boost? > > Thanks, > > Tim > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > -- Cory Nelson http://www.int64.org _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

RE: [boost] boost.thread : Can one create a thread with anobjectmember function?
by Tim Laplaca 23 Nov '04

23 Nov '04

Thanks, it turns out I don't need to object class so I dropped it. Tim -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov Sent: Monday, November 22, 2004 5:57 PM To: boost(a)lists.boost.org Subject: Re: [boost] boost.thread : Can one create a thread with anobjectmember function? Tim Laplaca wrote: > boost::thread_group thrds; > > objclass * objthread; > > > > objthread = new objclass; > > thrds.create_thread( (objthread->p) ); Do this instead: boost::shared_ptr<objclass> objthread( new objclass ); thrds.create_thread( boost::bind( &objclass::dowork, objthread ) ); Even better, drop the objclass entirely and do this: void dowork( int tid, string valtwo ) { // do work } thrds.create_thread( boost::bind( dowork, my_thread_id, my_valtwo ) ); _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[Review] Named parameter questions
by Thomas Witt 23 Nov '04

23 Nov '04

Hi, I was going to provide a (late) review for the named parameter lib, but I have some questions before I can do that. 1) I find the use of the name "keyword" for the type of the named parameter somehow odd. It does not seem to fit with what I associate with keywords. What's the rationale behind that choice. 2) The docs give the following example for mixing named and positional parameters: foo("bar", 3.14f); foo(value = 6.28f, "baz") Should print: bar = 3.14 baz = 6.28 I believe the parameter deduction in this case is too smart. Is there a way for the user of the library to enforce a rule like "No positional param after named params" on a case by case basis? 3) Section 5 has the following example // implementation of bar() template <class Params> void bar_impl(Params const& params) { // Extract arguments float x_ = params[x]; float theta_ = params[theta | pi]; float span = params[span || boost::bind(default_span, x_, theta_)]; //!! ^^^^ ^^^^ ... } IIUC this does not work. I assume the second span should refer to a named paramter object. I think it refers to the local span object. Did I miss something? Regards Thomas PS: Doug I know I am late, feel free to ignore me. -- Thomas Witt witt(a)acm.org

5 5