vanjalolz posted:

Ha Ha what the hell? Do Boost pointers actually add anything useful to warrant such terrible syntax?

Avenging Dentist posted:

Quick question, which hopefully That Turkey Story can answer: is there a library to support properties in C++ (a la C#)? If not, I'm going to write one...

That Turkey Story posted:

That Turkey Story posted:

code:

size_type const current_size = my_container->*size; my_container->*size = 10; // resize to 10

JoeNotCharles posted:

Haven't taken the time to read your code, but change "while true" to "for (int i = 0; i < 10; ++i)" or something so that it'll only run a few times. Then run it through valgrind with the --leak-check flag and it should tell you where the most obvious leaks are.

Creepy Doll posted:

Welp, there was a couple of minor errors along the lines of delete'ing where I should've delete[]'d, but they weren't in the main loop, but rather in the shutdown and such...

massif docs posted:

• The number of extra heap bytes allocated at that point. This reflects the number of bytes allocated in excess of
what the program asked for. There are two sources of extra heap bytes.
First, every heap block has administrative bytes associated with it. The exact number of administrative bytes
depends on the details of the allocator. By default Massif assumes 8 bytes per block, as can be seen from the
example, but this number can be changed via the --heap-admin option.
Second, allocators often round up the number of bytes asked for to a larger number. By default, if N bytes
are asked for, Massif rounds N up to the nearest multiple of 8 that is equal to or greater than N. This is typical
behaviour for allocators, and is required to ensure that elements within the block are suitably aligned. The
rounding size can be changed with the --alignment option, although it cannot be less than 8, and must be a
power of two.

Viper2026 posted:

code:

	if(number % 2 == 0){ //list is even in size
		left_half = new string[number / 2], 
		right_half = new string[number / 2];
		even = true;
	}
	else{ //list is odd
		left_half = new string[number / 2], 
		right_half = new string[(number / 2) + 1];
		even = false;
	}

Viper2026 posted:

I'm trying to write a merge sort function,

Viper2026 posted:

code:

result = new string[sizeof(list)];

Vanadium posted:

That sure will go over well in a data structures/algorithms class.

Stormtrooper posted:

Edit 2: New Question:
Anyone know how to correctly pass cyrillic characters in a path to ifstream?

cliffy posted:

If you were doing software development in the real world, then Ping's answer would be correct 99.999...9 % of the time. The biggest boon to productivity is access to libraries that have been thoroughly used, bug-tested/fixed, and tons of space/time efficiency tricks that you never would have thought of or taken forever to get right.

Wuen Ping posted:

You need to construct a wstring containing the path, then pass that to a wifstream. Cyrillic characters are outside of the ASCII set, so you have to use wide characters. ifstream cannot eat UTF-8 characters.

Vanadium posted:

That sure will go over well in a data structures/algorithms class.

Paniolo posted:

Your merge_sort returns a vector, but you aren't storing the result. I'm guessing your just printing the unsorted vector again. Look into passing by reference (that will also solve the stack overflow that will occur when you pass a vector of non-trivial size into a recursive sorting function.)

Viper2026 posted:

works partially, but result 9 prints:

9. terminate called after throwing an instance of 'std::out_of_range'
what(): vector::_M_range_check

Would changing my function prototypes to something like
vector<string> merge_sort(vector<string> *list, int number){
and then calling as vector<string> sorted_list = merge_sort(&names2, 10);
fix this?

Mustach posted:

std::out_of_range is thrown when you call at() with an index that's less than 0 or greater than or equal to the vector's size.

Viper2026 posted:

So does this mean I'm not correctly handling my sizes somewhere in my code?

(I've looked at it for a while now and I can't really see where the problem is, if you might be able to at least give me a hint from the code I linked above I would appreciate it)

Avenging Dentist posted:

code:

middle = number / 2;
// ...
left = merge_sort(left, middle);
right = merge_sort(right, middle);

Think about what happens when number is odd.

As an aside, you should really reduce the unnecessary copies you're making of your vectors. I count 3 copies of the full vector and 8 copies of the left/right vectors for every step of the merge sort.

Smackbilly posted:

pthreads question:

Is there any disadvantage to creating lots and lots of threads over the course of a program's execution, if only a couple will exist at any given time?

Smackbilly posted:

I could certainly consolidate timeout handling into one thread, but that would make the code messier and more complicated, so I'm inclined to avoid that unless there is a good reason to do it.