Re: [Boost-users] Boost Twitter is Blowing Up!!!
On 2022-06-21 at 16:12, Vinnie Falco via Boost-users wrote: On Mon, Jun 20, 2022 at 7:48 PM Good Guy via Boost-users wrote: The problem with Twitter is that it requires an account to read the posts. Yeah, so... my assumption when I made this post is that most folks have a Twitter account. I see that is not the case, even for long-time Boost authors. If you don't already have a Twitter account, there is not going to be much benefit to creating one just to like, follow, and retweet the Boost account, as you will have no followers and thus no reach. Although you might consider creating an account if you want to become more involved in C++ Twitter in general. That said, Twitter and the other socials might not be important to the senior engineers, authors, and maintainers here but collectively, Boost needs to catch up in terms of courting the younger generations of developers. We need fresh blood for library submissions, reviewers, and review managers. Our efforts on social media are aligned with this goal. Isn't the rule that when the seniors see a platform as mature enough to actually register and use it, the juniors have already desiced that it is un-cool and have moved somewhere else? ___ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
[boost] Re: Virus defense
Jarl Friis [EMAIL PROTECTED] skrev i meddelandet news:[EMAIL PROTECTED] [EMAIL PROTECTED] writes: Hello, Boosters - I am sure that many of you have received many e-mails from the [EMAIL PROTECTED] (http://securityresponse.symantec.com/avcenter/venc/data/[EMAIL PROTECTED] m.html ) e-mail virus. The problem with this virus is that it will spread itself to e-mail addresses - not just from Outlook's address book - but to any addresses it finds in the user's files. e.g., HTML files on the user's hard drive. e.g., HTML files that are part of the Boost distribution. That is not true! On the OS I am using it does not spread at all. All this is a *Windows* related issue/problem, No, it is not. It is a market penetration problem. It is no fun writing a virus for Linux, becase all 12 users would be infected immediately, and there it ends. If you write for Windows, you can infect a hundred million. Bo Persson ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: UI++ [was: GUI sublanguage;Re: Re: Re: Re: GUI/GDI template library]
Philippe A. Bouchard [EMAIL PROTECTED] wrote: Yeah I like Notus (kinda looks like Lotus). Exactly. Have you considered your reply when IBM's lawyers contact you over a possible trademark infringement? I immediately associated the name with Lotus Notes - I am sure they will to if Notus turns out it be successful. .-) Bo Persson [EMAIL PROTECTED] ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: time_duration bug in Boost 1.30.0
Paul A. Bristow [EMAIL PROTECTED] wrote: (And other MS specific unhelpful warnings which could be dealt with by #ifdef _MSC_VER or BOOST_? #pragma warning (disable : 4800) // inefficient bool conversion? #endif As a general point, is there any reason why 'known to be unhelpful' warnings like this cannot be disabled in Boost code? A problem here is that the inefficient bool conversion often actually *is* an inefficient implicit conversion to bool. IME, most of these warnings can be removed by actually producing a bool value. Adding == 0 or != 0 is often all it takes. Bo Persson [EMAIL PROTECTED] ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Review Request: cyclic_buffer
Alisdair Meredith [EMAIL PROTECTED] skrev i meddelandet news:[EMAIL PROTECTED] Bo Persson wrote: Instead of dropping elements when the buffer is full, we might also consider waiting or throwing a failure. The one true circular buffer template is a nigh impossible goal, because it means so many things to different people. Yes, sure. I just reacted to the suggested names cyclic_buffer and circular_buffer, which means slightly different things to me. In one case we have a cycle, like in your case with a few minutes of samples. The latest n samples are interesting, the older ones can be discarded. Another use for a circular (not cyclic :-) buffer is for the producer-consumer case, where some objects are queued temporarily. Here we can have the buffer wrap around at the ends, so we don't have to move any objects after a pop_front(). We can redefine the front position instead. If you run in a circle, you don't have an end case. Bo Persson [EMAIL PROTECTED] ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: class proposal
Justin M. Lewis [EMAIL PROTECTED] skrev i meddelandet
news:[EMAIL PROTECTED]
Not entirely, passing a pointer doesn't tell you that the parameter will
change, it just tells you that it might, it still leaves you in the
position
of having to track down the function and check it. But outside of that,
if
you're like me, at this point you prefer references to pointers, whenever
possible.
The obvious solution is of course to name the function so that you can tell
what is does! :-)
A function returning a single value, should really RETURN the value and not
update a parameter:
y = year_of_first_marriage();
Having a function lying about its purpose should be caught at its
definition, not at each call of the function:
void will_never_change_any_parameters_honest(int x) { x = 7; }
is easy to catch early. :-)
Bo Persson
[EMAIL PROTECTED]
- Original Message -
From: Vincent Finn [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, April 23, 2003 2:09 AM
Subject: [boost] Re: class proposal
void func(int x){x = 1977;};
void blah()
{
int y=0;
func(y);
func2(y);
printf(%d\n, y);
}
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Win32/VC++ 7.1 final beta regression tests posted
Beman Dawes [EMAIL PROTECTED] skrev i meddelandet [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... At 02:21 PM 2/18/2003, Peter Dimov wrote: Beman Dawes wrote: Because of interest in how well Boost 1.30.0 and VC++ 7.1 will work together, I've posted regression tests. See http://boost.sourceforge.net/regression-logs/ You might want to disable warning 4675, resolved overload was found by argument-dependent lookup. Yeah, I saw that too. But I don't want to put effort into VC++ 7.1 until (1) Boost 1.30.0 is out the door, (2) we have a release copy, (3) I finish some non-Boost work which is backing up. If you want to make changes yourself, feel free to do so. However, please test to make sure whatever you change doesn't screw up VC++ 7.0. Disabling this warning would hardly affect 7.0, as it is just an indication that 7.1 properly usues argument-dependent lookup, which 7.0 does not (except for operators...). A lot of the failures seems to be a warning that 7.1 actually does the right thing. A bit unfair to count this as a failure! Bo Persson [EMAIL PROTECTED] ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
