|
C89 posted:If either operand is negative, whether the result of the / operator is the largest integer less than the algebraic quotient or the smallest integer greater than the algebraic quotient is implementation-defined, as is the sign of the result of the % operator.
|
# ? Feb 16, 2013 02:13 |
|
|
# ? Jun 7, 2024 17:21 |
|
Hammerite posted:I was under the impression that given integers a and b (b not zero), if you write Ah, I see what you're trying to do. However, the function as posted is buggy: SensibleIntegerDivision(-5, -3) gives 0, where it should give +2 (if I understand you correctly). Edit: -2 should be +2. Thanks, Jabor! floWenoL fucked around with this message at 02:43 on Feb 16, 2013 |
# ? Feb 16, 2013 02:36 |
|
astr0man posted:If either operand is negative, whether the result of the / operator is the largest integer less than the algebraic quotient or the smallest integer greater than the algebraic quotient is implementation-defined, as is the sign of the result of the % operator. That is true, although you're leaving out the part where (a/b)*b + a%b is supposed to equal a. In that case, it's possible to write code that does what Hammerite wants regardless of the implementation.
|
# ? Feb 16, 2013 02:37 |
|
floWenoL posted:Ah, I see what you're trying to do. However, the function as posted is buggy: SensibleIntegerDivision(-5, -3) gives 0, where it should give -2 (if I understand you correctly). By the looks of what he's asking, it should be +2 in that case. It looks like he wants to subtract sign(b) (so add 1 when the denominator is negative, subtract 1 when it's positive) instead of always subtracting 1. I think.
|
# ? Feb 16, 2013 02:42 |
|
That's very embarrassing. The thing I had been using it for only used positive b (in fact, b = 2), so that's why I didn't notice any wrong results.
|
# ? Feb 16, 2013 07:31 |
|
I need a way to pass a program some integers with execlp. I've tried using sprintf to convert the numbers before I send them but it just kept giving me segmentation faults (I think this is just cause I didn't make room for the null terminating character but I'm not able to try it out right now), and I don't have access to itoa. Are there any better ways to go about this? Sprintf doesn't really seem ideal but from what I'm hearing casting an int to a char* in C isn't ideal anyway.
|
# ? Feb 18, 2013 18:38 |
|
Post your code? sprintf shouldn't segfault. Also you should use snprintf instead of sprintf.
|
# ? Feb 18, 2013 18:47 |
|
If i am trying to overload the [] operator in a vector how do I go about it? At present I have two typedefs code:
I am trying to overload pattern[] to return the number of true values at each position. EG If pattern looked like 1 0 1 1 1 1 0 0 1 0 1 1 1 0 1 0 pattern[3] would return 2 by means of trivial for loop. Is it possible to do this in a fashion that means it only happens when accessed out side of the class so within the class the operator is not overloaded? Perhaps by using some kind of namespace malarky?
|
# ? Feb 18, 2013 21:03 |
|
jiggerypokery posted:If i am trying to overload the [] operator in a vector how do I go about it? You can't change the interfaces of other classes (for good reason - it would be confusing as hell). The two ways to do what you want are actually to create a Pattern class with an overloaded operator [] or just create a free function int whateverTheOperationNameIs(const Pattern & p) (this way you don't get to use operator [], but what you're describing isn't an accepted thing that operator [] does so it would be considered bad practice to use it that way).
|
# ? Feb 18, 2013 21:27 |
|
Makes sense, I suspected as much. Thanks very much! (Still new to this!)
|
# ? Feb 18, 2013 21:35 |
|
I haven't programmed C++ for 8 years and was just a teenager when I did, now I hopped on to a project again and I'm fine because I've done a fair amount of pure C in the meanwhile but I can't figure out how to read this constructor definition(the class FingerPosition is a inherits from both Control and Note):code:
|
# ? Feb 19, 2013 04:28 |
|
In the definition of a constructor, after the function signature and before the opening brace, you can put a color and then a bunch of initializers, which will call constructors for member classes and base classes. You need to use initializer lists because after the opening brace every member and base will already have been constructed. The constructors are called in the order of their declaration as members (I forgot what the order for the base classes is, but regardless, this isn't something you should depend on because it gets very confusing).
|
# ? Feb 19, 2013 05:02 |
|
tractor fanatic posted:The constructors are called in the order of their declaration as members (I forgot what the order for the base classes is, but regardless, this isn't something you should depend on because it gets very confusing). Virtual bases, direct or not (if this is the ultimate type being constructed; otherwise, these are ignored), followed by non-virtual direct bases in the order they were specified as bases, followed by fields in order of their declaration in the class. The virtual base order is basically a depth-first post-order traversal, again in order of specification. Bases before fields and all in their original order is right enough in common cases. But yeah, it's usually poor style to rely on this.
|
# ? Feb 19, 2013 06:22 |
|
I can't work out what is wrong with this code. main.cpp: code:
error: no matching function for call to 'wrapperApplication::wrapperApplication(hexDrod (*)())' Yet if I change the first line to "hexDrod hd;" it compiles fine. I can't understand the error message and I can't see anything wrong with this code. Surely I'm just invoking the constructor for the hexDrod class? I have declared the constructor and all that jazz, and as far as I can see I got the syntax right. wrapper-application.h: code:
code:
code:
|
# ? Feb 19, 2013 09:45 |
|
Hammerite posted:It results in this error: When you write hexDrod hd(); you're actually declaring a function named hd that takes no arguments and returns a hexDrod. That's why the compiler thinks you're trying to pass a function pointer to wrapperApplication's constructor.
|
# ? Feb 19, 2013 09:53 |
|
e: the guy above me has a way better explanation
|
# ? Feb 19, 2013 09:58 |
|
Oh ok. So instead I should write the following (which compiles)?code:
|
# ? Feb 19, 2013 10:29 |
|
Why not just hexDrod hd;? That still invokes the default constructor, I'm pretty sure.
|
# ? Feb 19, 2013 10:59 |
|
Jewel posted:Why not just hexDrod hd;? That still invokes the default constructor, I'm pretty sure. Originally I had hexDrod* hd; wrapperApplication(hd); I noticed that the compiler gave a warning that hd was "used uninitialised", and then I twigged that that code does not actually create a hexDrod. It just declares a pointer to one, so if my application actually did anything as opposed to (at this stage) being an empty shell, I might see some bizarre behaviour. But I guess now that it is no longer declared as a pointer, this caution is no longer necessary.
|
# ? Feb 19, 2013 11:05 |
|
Hammerite posted:Originally I had hexDrod* hd; wrapperApplication(hd); Yeah, basically this: C++ code:
C++ code:
C++ code:
C++ code:
C++ code:
Because it's on the heap and not the stack, this will not be auto-deleted and you must 'delete hd;' yourself when done with it. Anything you use "new" for you HAVE to delete it too. C++ code:
It then creates a new pointer to a hexDrod object and points it to the memory address of 'hd'. Because you didn't use 'new' here you don't have to delete anything. Hopefully this helped! I'm not too good at this myself but this always helps me think about stuff. Please correct me if I'm wrong! Also this was all freehanded so hopefully I didn't forget something.
|
# ? Feb 19, 2013 11:17 |
|
Jewel posted:Hopefully this helped! I'm not too good at this myself but this always helps me think about stuff. Please correct me if I'm wrong! Also this was all freehanded so hopefully I didn't forget something. Thanks, this confirms what I thought but I also learned something about "new" and having to delete things that are allocated that way. I am puzzling a bit over how to structure the code in this project. I want to do things "the right way" so I end up with code that can be followed easily. I have the "wrapper application" which contains the main event loop, and event handling code that just determines the type of an event and calls individual event handlers in the hd child object. But I'm sort of just using the child object as a glorified namespace and I wonder whether it's a bit unnecessary to do it that way. Update: I realised that inheritance is the way to do this after all, rather than having member objects tied in to the object's functionality. Hammerite fucked around with this message at 12:15 on Feb 19, 2013 |
# ? Feb 19, 2013 11:27 |
|
Nippashish posted:When you write hexDrod hd(); you're actually declaring a function named hd that takes no arguments and returns a hexDrod. That's why the compiler thinks you're trying to pass a function pointer to wrapperApplication's constructor.
|
# ? Feb 19, 2013 15:39 |
|
Is it possible to make data structures require initialisation i.e have some kind of constructor? Or do I need to make PatternPreset a class in order to do that?code:
|
# ? Feb 19, 2013 15:50 |
|
There's no difference between structs and classes in C++ except that structs have default visibility public and classes have default visibility private. By convention structs are used for "plain old data" types and classes for more complicated things but it's just preconceived notions, it's not enforced by the language in any way. Edit: technically structs/classes also default to public/private inheritance respectively when not specified, though I've never really seen this come up in practice. seiken fucked around with this message at 16:01 on Feb 19, 2013 |
# ? Feb 19, 2013 15:56 |
|
So they actually all do have default constructors, you just don't have to actually type one out? That's good to know, thanks! Also I have commented an error I am getting with my constructor. Why is this a problem? Is there any work around? code:
jiggerypokery fucked around with this message at 16:08 on Feb 19, 2013 |
# ? Feb 19, 2013 16:02 |
|
it's a problem because the memory layout of arrays is determined largely at compile time; there's a special allowance made for 1d arrays with a runtime-determined size. workaround is to not use raw arrays. prefer std::vector or perhaps boost::multi_array
|
# ? Feb 19, 2013 16:11 |
|
I am a little confused. If i was to use the vector class, could I make a vector of 1d arrays who's size is dynamically allocated? If so how would that look?
|
# ? Feb 19, 2013 16:41 |
|
If you just want to be able to do pulses[i][j] then the easiest way is to make a vector of vectors, like std::vector<std::vector<int>>. However, this means you have to make a loop through the outer vector to set the lengths of each internal vector, and it's more overhead than is necessary since you don't need a jagged array. It also means two dereferences instead of one. If you don't want to use boost, the best way is to make a one dimensional array of your choosing, and make some helper functions to convert a two dimensional index into a one dimensional index.
|
# ? Feb 19, 2013 17:06 |
|
jiggerypokery posted:I am a little confused. If i was to use the vector class, could I make a vector of 1d arrays who's size is dynamically allocated? If so how would that look? std::vector<std::vector<whateveritcontains>> the_object; It's likely that "whateveritcontains" would be some sort of pointer because that way there can be subclasses and stuff, which is often what people want with their 2D arrays. You can't do std::vector<baseclass> for this because whatever child class is usually larger than a baseclass, and such a vector only allocates sizeof(baseclass) per element.
|
# ? Feb 19, 2013 17:06 |
Don't use arrays at all. Default to use a std::vector unless you can give a thorough explanation for why it's unsuited for your situation.
|
|
# ? Feb 19, 2013 17:07 |
|
roomforthetuna posted:It's likely that "whateveritcontains" would be some sort of pointer because that way there can be subclasses and stuff, which is often what people want with their 2D arrays. You can't do std::vector<baseclass> for this because whatever child class is usually larger than a baseclass, and such a vector only allocates sizeof(baseclass) per element. also because virtual methods only provide runtime polymorphism when indirected! this: vector<baseclass>[0].methodcall() would slice the object, calling baseclass::methodcall on its "base part", rather than subclass::methodcall
|
# ? Feb 19, 2013 17:10 |
|
nielsm posted:Don't use arrays at all. Default to use a std::vector unless you can give a thorough explanation for why it's unsuited for your situation. I disagree with this, but it probably doesn't matter much in practice. Use an array or a std::array unless the size is dynamic or if it is both large and you are putting it directly onto the stack.
|
# ? Feb 19, 2013 17:48 |
That Turkey Story posted:I disagree with this, but it probably doesn't matter much in practice. Use an array or a std::array unless the size is dynamic or if it is both large and you are putting it directly onto the stack. Right, I should have added the qualifier "for dynamic allocations" or something like that.
|
|
# ? Feb 19, 2013 17:53 |
|
You could always just do C++ code:
code:
|
# ? Feb 19, 2013 18:00 |
|
Thanks so much for all the help guys. Some really helpful stuff. I think the bottom line is the whole situation needed rethinking. Trying to brute force a solution isn't really the way to go. (I do like seikens approach despite the costs of readability). Going on what you guys have said about vectors being a better option for dynamic memory stuff i've gone with a vector of nested structures, and improved readability a whole lot. code:
jiggerypokery fucked around with this message at 19:48 on Feb 19, 2013 |
# ? Feb 19, 2013 19:46 |
Some suggestions: First is your constructors. You should make a habit of using initializer lists for everything possible, mostly because you will need to use them anyway when you start using types that need complex initialization as class members, but also because it's just the C++ way of doing it. C++ code:
Second, since the vector of presets has a complex access scheme (it's not just straight indices) and since the users of the class should not (as far as I can tell) be able to change the number of elements anyway, I would hide it as a private member and provide an access function. C++ code:
C++ code:
|
|
# ? Feb 19, 2013 22:47 |
|
Which is the best approach out of these two: Approach 1: global const bool arrays that may be checked against code:
code:
code:
code:
Hammerite fucked around with this message at 07:30 on Feb 20, 2013 |
# ? Feb 20, 2013 06:06 |
|
Hammerite posted:Which is the best approach out of these two: When in doubt, prefer exposing functions to exposing data. You can always define your functions in terms of lookups on static arrays under the hood. You might also want an assert or some error handling in your rounding function to back up your "no really big numbers" comment.
|
# ? Feb 20, 2013 07:11 |
|
greatZebu posted:When in doubt, prefer exposing functions to exposing data. You can always define your functions in terms of lookups on static arrays under the hood. You might also want an assert or some error handling in your rounding function to back up your "no really big numbers" comment. So something like this, you would say? (NB. I have changed the behaviour of the second one to allow both kinds of movement restrictions at once.) code:
code:
|
# ? Feb 20, 2013 09:20 |
|
|
# ? Jun 7, 2024 17:21 |
|
Ok yeah, The first part makes perfect sense. I have always used initialiser lists for classes that have lots of other things going on in the constructor and not if the constructor would be empty other wise. Personally I find it more readable but if that is bad form i'll switch to your way from now on. The second part I am a little confused about. nielsm posted:Second, since the vector of presets has a complex access scheme (it's not just straight indices) and since the users of the class should not (as far as I can tell) be able to change the number of elements anyway, I would hide it as a private member and provide an access function. Would calling the n accessor function not allow modification of the elements anyway? If it was; code:
Maybe I just need to read about constants because I often just want a variable you can only assign once, but you can not assign constants ever. Correct?
|
# ? Feb 20, 2013 10:35 |