Tag Info

New answers tagged

5

The core issue with threading here is that the parent thread will do stuff with the memory at the other end of those pointers, making them invalid. What you need to do is pass std::string into each thread. Not a reference, not a pointer, but a copy. Now each thread owns its own copy of the string, which will be automatically cleaned up via the magic of the ...


5

Because the c_str() doesn't prevent the string from being cleaned up. After the function returns and bar is cleaned up then the foo strings are also cleaned up which may be before the thread starts. You should pass the actual std::string (possibly to a wrapper that then extract the char* before calling func) or otherwise ensure the strings don't get cleaned ...


0

You describe a situation in which the user updates three rows. The first transaction completes after the third click, and all three rows update themselves with the stale data. You need to think about the granularity of your model items. It sounds like you want each row on the UI to represent a single aggregate (transactional boundary). So when an aggregate ...


0

Focus on the problem, not the solution. Taking this problem back to abstract terms, you've got a scenario that screams out for multiple processes communicating via queues. One process (the "input reader") would loop reading items from your input list (CIDR blocks) and append them to a to-be-enumerated queue. A second set of processes (the "enumerators") ...


0

You need to break this down into two steps: First, use python to parse the text file and generate a list of IP address that are easy to consume in C. Second, let's look at the exact problem. You want to "connect" but you are not going to read or write. I am not sure what the purpose of this is. Couldn't you use ping to accomplish the same thing? If you ...


2

Java implements the Java Memory Model which states what should happen in certain situations, and dumping core is not mentioned anywhere in this document. So any Java implementation must take care to implement what the memory model says, and thus throwing core is not permitted. It does sometimes happen, though rarely, but only as a result of bugs in the ...


0

@ratch freak's answer is correct but the reason for the segfault is likely to be slightly different. std::vector holds its values in place. In the case of std::vector<int> that just means that it contains an array of ints. For objects it means it uses inplace new. So, on a re-allocation of the internal array, any extraneous reference to the original ...


1

Consider the effects race conditions can have on actual hardware, not in the C++ undefined behavior theory. On the high level, you get unpredictable insertion order, possibly lost insertions, or even corrupted data structures. You can totally get these in Java. (If you do racing insertions/removals on a LinkedList for long enough, eventually you'll probably ...


0

It's a question of preference. Core dumps can only happen in a (properly implemented) language runtime if you invoke undefined behaviour, since they are never desired; and the designers of Java went to very great length to banish all undefined behaviour from the language. The attitude of the C++ community tends to be "We need to make it possible to achieve ...


2

In std::vector when a reallocation happens the old array is explicitly deleted, in java.util.ArrayList on the other hand, the old array is left to the garbage collection. And the GC is conservative enough that the other thread's reference to the array will prevent it from being cleaned up. but when memory could literally be pulled out from under the ...


2

You're going to struggle to make this work as well as you're hoping. The precise figures vary depending on operating system, but if you try opening more than a few hundred sockets at a time on an ongoing basis you're going to start running out of system resources pretty quickly. On windows desktop machines the limit is lower still (windows desktop prevents ...


3

Your first link does address the issue - it's laziness combined with side effects that is problematic, because the order of side effects matters. For pure computations, the main thing that changes is space/time usage and whether the computation produces a result or not. More specifically, lazy evaluation won't evaluate expressions that aren't used, so the ...


0

It seems like each song is processed independently, in which case you just need parallel collection. Quick googling found this gem: https://github.com/grosser/parallel Code would be something like that: Parallel.each(songs) do |song| lastfm.track.scrobble artist: song[:artist], track: song[:track] puts "Scrobbled #{song[:track]} by #{song[:artist]}." ...



Top 50 recent answers are included