|
This distinction is easy. An output parameter is one that you overwrite completely.
|
# ? Dec 3, 2015 04:04 |
|
|
# ? Jun 7, 2024 03:21 |
|
sarehu posted:This distinction is easy. An output parameter is one that you overwrite completely. So, not a container that you append to, then.
|
# ? Dec 3, 2015 13:45 |
|
Hubis posted:So, not a container that you append to, then. No, just like passing in a writable file descriptor doesn't make it an output parameter, nor would an object reference on which you call a method with side effects.
|
# ? Dec 3, 2015 16:30 |
The value of an output parameter may be undefined at function entry, the value of the output parameter will typically have changed at function exit, and the operation of the function will still be well-defined (assuming nothing else occurs in the function can cause UB.)
|
|
# ? Dec 3, 2015 17:00 |
|
Subjunctive posted:No, just like passing in a writable file descriptor doesn't make it an output parameter, nor would an object reference on which you call a method with side effects. I guess my point is that I don't think that delineating between "output parameters" and "parameters wot could have side effects" seems particularly useful from a readability perspective: - If you have code that takes a pointer to an object that isn't an output parameter then you're going to have address decorators in the call anyways - If you have code where you have a pointer to the object you want to use as the output for some reason then you would be lacking the decorator you're claiming helps to make the code more readable. - The meaning of what is an "output" parameter seems kind of arbitrary to me. Why do you need to know what's an input and what's an output, and how is that different from something which is simply modified rather than "completely overwritten"? Really it sounds like the advice is really more just "don't use non-const references, so you know anything you pass a pointer to COULD be getting changed" but to me that just becomes "be really aggressive about marking things as const". I mean, this is all borderline stuff -- I can't imagine a codebase where readability is going to be made or broken one way or another by this. It's easy to sound judgmental about religion and programming languages. I just keep asking about it because hearing how other people thing about programming and language artifacts like that is really interesting and useful for me. For example, is there any reason why you couldn't extend the code Plorkyeran posted to have a different type for pointer parameters the function would maintain references to? Is there any advantage to using a const reference versus a const pointer? etc.
|
# ? Dec 3, 2015 20:04 |
|
An output parameter is something that would be a return value if the language had a good way to return multiple values. It's really not very complicated or abitrary at all.
|
# ? Dec 3, 2015 20:43 |
|
Plorkyeran posted:An output parameter is something that would be a return value if the language had a good way to return multiple values. It's really not very complicated or abitrary at all. .. by reference. Because you can completely return a structure without problem right now, but that's not always desirable because of size limits. So you're saying an output parameter should have the same properties as an r-value: undefined before the function, and guaranteed to be defined after the function runs (really it's the rvalue and lvalue at the same time). I guess I just don't understand the usefulness of trying to make this very obvious in the code, regardless of whether assuming that the address-of operator is a useful way of conveying it. Static analysis, i.e. "it's ok that this hasn't been initialized before being passed into this function"? It seems like "is a pointer" isn't really sufficient for that.
|
# ? Dec 3, 2015 23:21 |
|
It's not as useful as the const/non-const delineation but it's still useful. You know, just looking at the callsite, some information about whether a variable's previous state is going to survive.quote:.. by reference. Because you can completely return a structure without problem right now, but that's not always desirable because of size limits. No the problem is that there's no convenient way in the code to unpack the multiple return values in C++. sarehu fucked around with this message at 00:01 on Dec 4, 2015 |
# ? Dec 3, 2015 23:58 |
|
I don't find defining throwaway structs and accessing their members to be at all onerous Given that typing is certainly not the hard part of programming, a few extra characters compared to some ideal pattern-matching world is not a very high price to pay for unambiguous readability.
|
# ? Dec 4, 2015 08:09 |
|
Do ranged-based for loops iterate once, even when the container is empty? I've resolved it by other means, but I have an object with a vector member full of pointers that may or may not be empty when this object's destructor is called. I was doing this:code:
Edit: Looking at it, I guess it makes sense that this fails because if it's empty, vector::begin() returns an iterator and "the returned iterator value shall not be dereferenced." Phayray fucked around with this message at 08:17 on Dec 4, 2015 |
# ? Dec 4, 2015 08:12 |
|
No, that does not make any sense. The loop will never dereference any iterators if the collection is empty. Unless these are hand-written (buggy) iterators, your bug is somewhere else; perhaps the object has already been destroyed? Reasoning abstractly about your code is good, but sometimes you just need to look at it in a debugger.
|
# ? Dec 4, 2015 08:30 |
|
No, although the returned iterator shouldn't be dereferenced if the container is empty, the iterator will be equal to the end iterator and the loop will ever execute its body. Something else is up. E:
|
# ? Dec 4, 2015 08:30 |
|
Derp, of course you guys are right, I was deleting them somewhere else but not clearing the vector. Saw it as soon as I looked at it this morning, I guess I just needed some sleep!
Phayray fucked around with this message at 15:37 on Dec 4, 2015 |
# ? Dec 4, 2015 15:26 |
Why would I suddenly be getting a linker error telling me that the OpenGL libraries weren't found? The only thing I changed is that in stead of using dynamic libraries for assimp, I now compile it with my project and link it statically. The assimp library file links up just fine, the linker error is on my main executable. This only happens on Linux (gcc 4.8.2) while it compiles fine on Windows (MinGW 5.0.2). This is the output from ld:code:
code:
|
|
# ? Dec 5, 2015 03:56 |
|
There isn't a static version of libGL
|
# ? Dec 5, 2015 08:10 |
pseudorandom name posted:There isn't a static version of libGL Can the -static flag I put there for -pthread affect this line? code:
Joda fucked around with this message at 10:59 on Dec 5, 2015 |
|
# ? Dec 5, 2015 10:52 |
|
-static is all or nothing.
|
# ? Dec 5, 2015 11:10 |
|
There might be a way to use incremental linking to just statically link specific libraries, but it will break any dynamic libraries you use that depend on those libraries, which for pthreads probably includes libGL.
|
# ? Dec 5, 2015 18:34 |
|
Phayray posted:Derp, of course you guys are right, I was deleting them somewhere else but not clearing the vector. Saw it as soon as I looked at it this morning, I guess I just needed some sleep!
|
# ? Dec 5, 2015 19:33 |
I did some testing and you're right; removing -static from the list of flags fixes the issue. However, I'm still linking four other libraries (on top of glibc and libsdc++) statically; only I'm doing it by compiling them alongside the project, as opposed to linking them with a compiler flag. How are these two fundamentally different? I'm still just compiling a library file, then linking it against my main executable at the end. E: Not to mention the fact that it actually works as intended on MinGW with the -static flag? Joda fucked around with this message at 21:31 on Dec 5, 2015 |
|
# ? Dec 5, 2015 21:07 |
|
Anyone here familiar with openCL? I have a program here that takes in two arrays, one of size=10 ArrayA and another of size=100 ArrayB. I have a 2D Kernel that does 10*10 operations to fill ArrayB with values where each element is equal to the unique global id of the current work item/kernel. The problem is that when I copy ArrayB back, I only have valid values for the first ArrayA-sized elements, the rest are garbage. I know the kernels are running for 100 elements because I have a count incrementer and it equals 100 when it finishes, so 100 kernels had to have operated. SimpleArray: code:
code:
e: So this example for inexplicible reasons works when: ret = clSetKernelArg(kernel, 2, sizeof(int), &memobj_a_size); is changed to: ret = clSetKernelArg(kernel, 2, sizeof(int), &_size); This is just strange to me. Raenir Salazar fucked around with this message at 21:45 on Dec 5, 2015 |
# ? Dec 5, 2015 21:20 |
|
According to the docs for clSetKernelArg, the kind of arg_value you're supposed to pass depends on the type of the argument, which I assume it knows by just looking at the compiled kernel function. Basically:
I don't know why the documentation is written so badly; I feel like this table should be obvious on that webpage, not something you have to awkwardly infer.
|
# ? Dec 6, 2015 01:11 |
|
rjmccall posted:According to the docs for clSetKernelArg, the kind of arg_value you're supposed to pass depends on the type of the argument, which I assume it knows by just looking at the compiled kernel function. Basically: I'm not sure, the main issue of confusion for me is that the problem really should've been with: code:
code:
|
# ? Dec 6, 2015 04:08 |
|
It is literally copying the first sizeof(int) bytes out of the object header of some buffer you allocated and passing that as the int argument. You might have other problems but it is not surprising that that is one of them.
|
# ? Dec 6, 2015 07:33 |
|
Ralith posted:AddressSanitizer would have made this immediately obvious. Try it next time! This is great, thanks!
|
# ? Dec 6, 2015 15:20 |
|
Joda posted:I did some testing and you're right; removing -static from the list of flags fixes the issue. However, I'm still linking four other libraries (on top of glibc and libsdc++) statically; only I'm doing it by compiling them alongside the project, as opposed to linking them with a compiler flag. How are these two fundamentally different? I'm still just compiling a library file, then linking it against my main executable at the end. A static library (collection of .o files that will be copied into your eventual, dynamically linked program) is different from using the -static gcc flag (try and make a program only out of static libraries, no shared libraries at all not even libc). The only reason you'd do the latter is for compiling things like basic utilities in /bin that you want to work even if you somehow mess up/delete glibc.
|
# ? Dec 7, 2015 12:28 |
feedmegin posted:A static library (collection of .o files that will be copied into your eventual, dynamically linked program) is different from using the -static gcc flag (try and make a program only out of static libraries, no shared libraries at all not even libc). The only reason you'd do the latter is for compiling things like basic utilities in /bin that you want to work even if you somehow mess up/delete glibc. The reason I want to link the standard libraries and pthread statically is that I want to avoid having to redistribute their dlls with my program on WIndows (on Linux I don't really care, because installing the standard libraries is a pretty fast process.) The main reason is that while the GNU standard library license clearly states that you can redistribute a statically linked binary file however you want, I can't find any clear language on whether that exemption from the GPL extends to dynamic linking and redistribution of the C and C++ standard library .dll's. That said I guess pthread is under a permissive license, so I could just settle with linking libc and c++ statically and then redistribute with libwinpthread.dll.
|
|
# ? Dec 7, 2015 12:44 |
|
Two notes:
What exactly is your issue? Can you explain using actual library or file names? From the sounds of it you should be able to statically link both of those.
|
# ? Dec 7, 2015 17:49 |
Doctor w-rw-rw- posted:Two notes: Really? I'm pretty sure I read that the GNU standard libraries (C/C++) were under the GPL, but exempt in such a way that you could link them statically and redistribute your binary without restrictions. I may have misunderstood what I read though. Doctor w-rw-rw- posted:What exactly is your issue? Can you explain using actual library or file names? From the sounds of it you should be able to statically link both of those. I was getting a linker error on OpenGL (ld couldn't find -lGL), because I was using the -static flag to link pthread statically. Obviously I can't link OpenGL statically, because its concrete implementation varies depending on hardware and driver versions.
|
|
# ? Dec 7, 2015 18:01 |
|
Ah, okay.Joda posted:Really? I'm pretty sure I read that the GNU standard libraries (C/C++) were under the GPL, but exempt in such a way that you could link them statically and redistribute your binary without restrictions. I may have misunderstood what I read though.
|
# ? Dec 7, 2015 18:11 |
|
feedmegin posted:The only reason you'd do the latter is for compiling things like basic utilities in /bin that you want to work even if you somehow mess up/delete glibc. Fun fact: the s in /sbin stands for static and was for that purpose, only later was it decided that it was for administrator programs and not included in PATH by default. The /sbin vs /usr/sbin was because they ran out of space on the drive that / was mounted at, and moved binaries that weren't needed to mount the /usr drive, which at that point was for users' files. After they filled that up with binaries they put another drive in, mounted it at /home and put users' files on there, hence the weird names for /usr and /home.
|
# ? Dec 7, 2015 23:44 |
|
I learned something new today.code:
|
# ? Dec 8, 2015 03:03 |
|
Zero? Because you wrote the ()?
|
# ? Dec 8, 2015 03:08 |
|
Under Microsoft compilers it was -1, under Clang it was 0. My actual case was a bit more complex though, not sure how VC++ would process the more trivial example. I definitely did not expect placement new to value-initialize.
|
# ? Dec 8, 2015 03:15 |
|
Paniolo posted:I learned something new today. This is how initialization of new expressions are handled 5.3.4.17 posted:A new-expression that creates an object of type T initializes that object as follows: So "new (&f) foo" is default-initialized. "new (&f) foo()" is direct-initialized, and the specific rule for that we're interested in is 8.5.17.4 posted:- If the initializer is (), the object is value-initialized. which eventually gets you to zero-initialization.
|
# ? Dec 8, 2015 05:10 |
|
also i think direct-initialization for T() only became a thing in c++03, so knowing Microsoft and backwards compatibility/standards compliance they decided to keep the legacy behavior.
|
# ? Dec 8, 2015 05:12 |
|
The use of () to mean zero-initialization is just the stupidest thing. I mean C++ gets a lot of dumb poo poo from C, but this is a special gift from C++.
|
# ? Dec 8, 2015 05:15 |
|
Paniolo posted:Under Microsoft compilers it was -1 It's 0 with VS2015
|
# ? Dec 8, 2015 06:01 |
|
sarehu posted:The use of () to mean zero-initialization is just the stupidest thing. I mean C++ gets a lot of dumb poo poo from C, but this is a special gift from C++.
|
# ? Dec 8, 2015 09:34 |
|
|
# ? Jun 7, 2024 03:21 |
|
OneEightHundred posted:Unless you consider non-initialization to be dumb poo poo from C.
|
# ? Dec 8, 2015 13:06 |