issue with multithreading a function

[tsftd]

So I'm rewriting a program to include multithreading (among other things), and I've got a strange problem:

boost::thread alpha(preparray,&from[0][loop],&to[0][loop],&tol[0][loop],&toc[0][loop],of1,of2,of3,ramletter,&lock[tempint]);

works -- i just take the existing array, and change the beginning from preparray(&from[0][loop]... to boost::thread alpha(preparray,&from[0][loop]

boost::thread alpha(threadctr,&from[0][loop],to[0][loop],&froml[0][loop],tol[0][loop],&fromc[0][loop],toc[0][loop],offbits[22],cropxres,cropyres,cropxoffset,cropyoffset,cropmethod,offbits[26],fuzzcolor,fuzzgray,trimmethod,offbits[25],rotatedegrees,flipflop,rotationmethod,rotationtrim,of1,of2,of3,jpegtran,&lock[tempint]);

on the other hand, doesn't work. threadctr(&from[0][loop]... works fine -- so it's not a problem with the function (or the large number of arguments being passed), but the compiler gives the following error (after changing to the threaded version): 'error: no instance of constructor "boost::thread::thread" matches the argument list', and trying to compile throws: error C2661: 'boost::thread::thread' : no overloaded function takes 27 arguments

the ONLY thing i can think of is that maybe boost has a lower limit on the maximum number of arguments a function can be passed? if so, does anyone know what it is?

[Cubbi]

Yes, boost has a limit on the number of arguments passed to bind(), which is what thread constructor uses. You'd need a compiler with sufficient C++11 support, or pass a struct.

[o1vk4iN6]

Why are you passing so many arguments in the first place ? It reduces readability greatly.

[tsftd]

first of all, thanks for the incredibly fast replies!

well, readability isnt an issue as this is a personal project.

basically i am performing multiple transforms on an input image using magick++, and the arguments passed have the arguments from the commandline to apply to these transforms.

the issue is that it's going to be very difficult to break this into multiple functions, because it's threaded and working in a chain. in other words, this is the way it works now:

call function in thread
load image into memory
crop
trim
rotate
write image

however, if i call multiple functions i must write the image for each transform. or in other words i must crop every image and write them, then trim every image and write them, etc. which is much less efficient.

i guess i'll just have to use structs. i was avoiding that because of the increased overhead (not much, granted) and increased code complexity. plus now ill have to rewrite the REST of the program to use the structs... sigh...

[o1vk4iN6]

readability isnt an issue as this is a personal project.

Readability is always an issue, it doesn't matter how big or small the project is (a small project could eventually expand into a bigger one), if you learn by writing sloppy code you'll continue to do so. It's not like it takes more effort to write cleaner code.

i guess i'll just have to use structs. i was avoiding that because of the increased overhead (not much, granted) and increased code complexity

Why ? If you ask me having 27 arguments is increasing the complexity more than a struct would.

[tsftd]

because it means that i need to make structs for pretty much all of my parameters -- of which there are well over 100. so instead of lzma2litconbits,lzma2litposbits,lzma2posbits i need to make struct lzma2 with elements litconbits,litposbits,posbits... not a huge difference, but it's additional work. also, it means i needed to look up struct. i'm not a trained programmer, i do c++/basic/javascript/php/various scripting languages, but I more or less just start a project and look up how to do what i need to do as i go along. thankfully structs are quite a bit easier than, say, threading was, plus of course now i know structs... but it did add some additional work for me.

and my code is incredibly hard to read, but to some degree there is a method to the madness. i hate having to scroll thru code, so i tend to compress it as much as possible so i can see larger chunks of the code in one screen. makes it much harder for others to read, but i've got my own sorts of standards, ie:

if(tempstring=="#Default 64deflate"){
	tempint++;getline(inifile,tempstring);if(tempstring=="OFF")offbits.set(0,1);else{
		deflate64fastbytes=strtoint(tempstring);checkinint(deflate64fastbytes,3,257,1,1,tempint);
		tempint++;getline(inifile,tempstring);deflate64passes=strtoint(tempstring);checkinint(deflate64passes,1,15,1,2,tempint);
}}if...

is typical for me -- and since im used to it, i can read it perfectly fine. granted, if i were ever to code professionally, or work on a joint project, i'd need to adjust my coding, but i don't see that ever happening.

[Zephilinox]

I'm the opposite, I keep to good coding style and using the standard because if I were to code professionally, I'd already be used to the cleanliness.

that for example would quickly cause me to use a code style modifier, it's so damn cramped.

if (tempstring == "#Default 64deflate")
{
    tempint++;
    getline(inifile, tempstring);
    
    if (tempstring == "OFF")
        offbits.set(0, 1);
    else
    {
        deflate64fastbytes=strtoint(tempstring);
        checkinint(deflate64fastbytes, 3, 257, 1, 1, tempint);
        tempint++;
        getline(inifile, tempstring);
        deflate64passes = strtoint(tempstring);
        checkinint(deflate64passes, 1, 15, 1, 2, tempint);
    }
}

and even then that is hard to read, because the variable names have no casing whatsoever, normally either a dash, underscore, pascal (a.k.a upper CamelCase) or lower camelCase is used, as it makes it easier to read the names individually instead of as a whole word.

[tsftd]

right, though in my case for instance tabbing at line 7 would confuse me as for my own purposes i only ever tab to indicate braces (thought not always -- if it's a couple of small related operations in the braces i'll leave it as one line).

i'm also notoriously bad about documentation -- this is the first program i've even done rudimentary documentation, but of course when it's only you, you only need it if you want to remind yourself of what you've done.

anyways, this pretty clearly demonstrates the advantages and drawbacks -- in my case, it takes up fewer lines, and in yours, it's easily readable. trust me, you don't want to see my whole program...

[Zephilinox]

^^ you're right, I probably don't.

I tab at line 7 so it is clear that the offbits.set is part of the if statements scope, since I didn't bother to add curly brackets, if it is short enough you could put it all on the same line but then if it is too long you'd end up splitting it again, making an inconsistent style