- Boost - lists.boost.org

Re: [boost] Warning. Possible virus at vault (thread_lokeable)
by raindog＠macrohmasheen.com 27 Jun '09

27 Jun '09

If anyone still has a copy of it somewhere, can you send it to me? ------Original Message------ From: Rene Rivera Sender: boost-bounces(a)lists.boost.org To: boost(a)lists.boost.org ReplyTo: boost(a)lists.boost.org Sent: Jun 27, 2009 6:47 AM Subject: Re: [boost] Warning. Possible virus at vault (thread_lokeable) Niels Dekker - address until 2010-10-10 wrote: > Agustín K-ballo Bergé wrote: >> The recently uploaded 'thread_lokeable' file at the vault contains an >> executable that appears to be a virus. virustotal.com reports 6/41 hits. >> The name of the owner (marc0x) appears at some hacker related forums. >> >> I don't know what should be done in such cases, so I hope some >> administrator would read this message and take a look at the file. > > I don't know what to do either, but I've just mailed your finding to > Info (at) boostpro.com > > FYI, I've just downloaded the file, thread_lokeable.zip, and AVG > reported to me that the executable it contains (thread_lokeable.exe) is > a "Trojan horse Dropper.VB.CFQ" Thanks for noticing and reporting it. It's taken care of. Although I may have deleted an extra user or two along the way :-\ -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Sent from my Verizon Wireless BlackBerry

1 0

Warning. Possible virus at vault
by Agustín K-ballo Bergé 27 Jun '09

27 Jun '09

The recently uploaded 'thread_lokeable' file at the vault contains an executable that appears to be a virus. virustotal.com reports 6/41 hits. The name of the owner (marc0x) appears at some hacker related forums. I don't know what should be done in such cases, so I hope some administrator would read this message and take a look at the file. Agustín K-ballo Bergé.-

3 2

[hash][msvc 8.0] <boost/functional/hash/detail/float_functions.hpp> issuing a using namespace std directive?
by JOAQUIN M. LOPEZ MUÑOZ 27 Jun '09

27 Jun '09

If I compile the following wih MSVC++ 8.0: #include <list> typedef list<int> foo; the compiler complains, fairly enough, with some syntax error due to the fact that there's no "list" in the global namespace (we missed a prefixing std::). But if I now try this: #include <boost/functional/hash/detail/float_functions.hpp> #include <list> typedef list<int> foo; compilation succeeds! Somehow, <boost/functional/hash/detail/float_functions.hpp> is importing namespace std into the global namespace, presumably with a using directive. I tried to examine the offending header an saw no obvious using directive to blame, so I hope someone more knowledgeable can take a look at this problem. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

7 19

[function] Unmerged changes and open tickets
by Daniel James 27 Jun '09

27 Jun '09

Hi all, Boost.Function doesn't seem to have been merged to release for the last 8 months. There are also a number of open tickets which look fairly easy to fix. So, if no one objects, I'll try to deal with them in a few days time and then merge outstanding changes a little while later. These tickets fix various problems: https://svn.boost.org/trac/boost/ticket/2642 https://svn.boost.org/trac/boost/ticket/2847 https://svn.boost.org/trac/boost/ticket/2929 https://svn.boost.org/trac/boost/ticket/3012 There's also an optimization which looks sensible to me: https://svn.boost.org/trac/boost/ticket/2319 Daniel

1 0

[ptr_container] ptr_vector across DLL boundaries
by Robert Dailey 27 Jun '09

27 Jun '09

Hi, Suppose I have a DLL that allocates a few objects and places them in a ptr_vector. I then pass this ptr_vector to my executable via a move operation (basically a swap, not a copy). The executable would keep the ptr_vector by value and eventually delete it when it falls out of scope. Is there any danger in doing this? My goal is to make sure that the same memory manager is used to delete the items as was used to create them.

5 28

[variant] Visual Studio debug visualizers
by Dmitry Vinogradov 25 Jun '09

25 Jun '09

I wrote a simple debug visualizer for boost::variant and I want to share it with community. boost::variant<*,*,*,*,*,*,*,*,*,*,*> { preview ( #( #switch($c.which_) #case 0 ( *($T1 *)&($c.storage_.data_) ) #case 1 ( *($T2 *)&($c.storage_.data_) ) #case 2 ( *($T3 *)&($c.storage_.data_) ) #case 3 ( *($T4 *)&($c.storage_.data_) ) #case 4 ( *($T5 *)&($c.storage_.data_) ) #case 5 ( *($T6 *)&($c.storage_.data_) ) #case 6 ( *($T7 *)&($c.storage_.data_) ) #case 7 ( *($T8 *)&($c.storage_.data_) ) #case 8 ( *($T9 *)&($c.storage_.data_) ) #case 9 ( *($T10 *)&($c.storage_.data_) ) ) ) children ( #( value: #switch($c.which_) #case 0 ( *($T1 *)&($c.storage_.data_) ) #case 1 ( *($T2 *)&($c.storage_.data_) ) #case 2 ( *($T3 *)&($c.storage_.data_) ) #case 3 ( *($T4 *)&($c.storage_.data_) ) #case 4 ( *($T5 *)&($c.storage_.data_) ) #case 5 ( *($T6 *)&($c.storage_.data_) ) #case 6 ( *($T7 *)&($c.storage_.data_) ) #case 7 ( *($T8 *)&($c.storage_.data_) ) #case 8 ( *($T9 *)&($c.storage_.data_) ) #case 9 ( *($T10 *)&($c.storage_.data_) ) ) ) }

3 8

Fixed point structure size
by Soren Holstebroe 25 Jun '09

25 Jun '09

Hi, An important feature of the fixed point template is that it takes up no more space than the underlying integer. It should be possible to use reinterpret_cast to convert a third party integer pointer (representing fixed ints) to a fixed point template pointer. The way I ensure that in my fixed point template is with a #pragma: #pragma pack(push, 1) ... template struct ... #pragma pack(pop) This is supported by MSVC++ as well as gcc. However it is only defacto standard, so it might not work on any other compiler. Is there a more standard way to make sure that the struct is not padded to some memory alignment size? Soren

2 1

Re: [boost] Fixed point integer proposal
by Soren Holstebroe 25 Jun '09

25 Jun '09

> For example, does a(24bit) x b(24bit) -> c(24bit), or c(48bit)? > > My preference is to be explicit about these issues, meaning 24bit x 24bit -> > 24 bit. If you want more, you cast the operands first. Similarly there > were some questions on division. In my template N bit x N bit equals N bit per default. The number one design criteria was speed. Why would you use fixed point instead of floats if not for speed? I agree that you should be explicit if you want to promote the return type of a multiplication. That said, my template actually work with a promotion framework I wrote, where you can specify the promoted type of different kind of operations for different types. In the image processing library where the class was used, the promotion framework was set to promote N bit * N bit to 2N bit, but only up till the maximum number of bits natively supported by the CPU architecture. It was combined with an overflow check in debug mode to avoid surprises when the promotion was at the bit loft. That worked pretty well (and speedy). > My implementation also uses boost::operators. In addition, I have 2 > versions, one which the bit-widths are set at compile time, and the other > set at runtime (I use the latter to expose to python). I can't see a way to support run time bit width without sacrificing performance. Soren

3 5

Re: [boost] Linear circular buffer
by Soren Holstebroe 25 Jun '09

25 Jun '09

Hi Dean, >> The boost library contains a circular buffer template by Jan Gaspar. It > I use it just fine in my high performance applications where I > maintain the most recent N timings from API calls. Although iteration > through the dataset may be a little painful, N is not large enough for > me to notice (100 and 1000) the pain. The calls run in sub-microsecond > time and the maintenance of automatically evicting older entries gives > me (the user) a good guarantee that the data I'm getting is > consistent. I think your example is from a scenario where buffer processing is not where most of the cpu time is spent. In that case Jan Gaspars circular buffer is just fine. In fact, if what you want to do is to aggregate a linear response (like an average function), all you have to do is to look at the item going out of the buffer and item going in, you wouldn't even have to look at whats in the middle of the buffer. If your use of circular buffers is in applications, where buffer processing is what the application is all about, then sub-microseconds matter, if you are talking about 1 billion times 5 microseconds vs 1 billion times 3 microseconds. One example is bioinformatics, where you want to drag a window across the whole 3+ gigabases genome and maybe calculate some entropy measure in that window. Another is FIR filters in DSP, where you produce an output by convolving each window with a second buffer. > I agree about read performance, but I don't think you ever need to > call 'linearize' if you don't intend to build a vector out of your > circular buffer. If your buffer processing is done by an external library, then you need to linearize. In image processing and DSP, that would be a very common situation. > Iterating through the container is O(N) where N is > the size of the container, and the check for borders is O(1); In the case where your buffer processing can use the iterators, the overall complexity is the same, but the constant is not. You save a border check if your buffer is linear. > I can imagine that you can use the modulo (%) function given that you know > the initial offset of the "first" entry in the buffer, and N being the > size of the buffer Modulo is (at least in the old days) calculated as the remainder of a division. That is much slower than a border check. > How about space efficiency then? I (the user) expect to have just 100 > elements' worth of memory used when I allocate 100 elements' worth of > a circular buffer at construction time (same goes for the STL vector). First, are you sure you get 100 elements allocated when you resize a vector to 100? A vector implementation might reserve a whole chunk of memory for you when resize to make the next potential reallocation faster. Anyway, my proposal is about speed and the allocation of, lets say 100, extra elements would not be an issue in all practical high throughput application I can think of. > Linear access time is nice especially if you intend to always just go > through the whole data structure everytime -- having said this I don't > think I'd necessarily want to pay for extra space usage if I can > absolutely avoid it. I have the exact opposite priority. I would not trade performance to save a few hundred bytes, that might have been allocated anyway by the allocator (or system paging or whatever). > How do you intend to implement the internal buffer then without having > to use more memory than necessary to store the elements? As discussed, you are, as far as I know, not guaranteed that with std::vector either in most implementations. Soren

1 0

Re: [boost] Fixed point integer proposal
by Soren Holstebroe 25 Jun '09

25 Jun '09

> 2009/6/25 Andrey Upadyshev <oliora(a)gmail.com> >> >> Yes, it is very interesting. I think it will be also useful in finance calculations. >> > > Actually, on that note, would it be possible to allow an arbitrary > scale factor instead of specifying a shift? It ought to still be as > efficient for power-of-two scales, on the assumption that compilers > optimize multiplication and division by such constants... I suppose that it would indeed be possible to use an arbitrary scale. If it is unclear if the compiler will optimize correctly, it should be straight forward to implement a scaling template with power-of-two as template specializations. Soren

1 0