Hai, I'm a newfag to C++ and to this board so excuse my giant amount of fail.
Why won't this figure out the smallest thing in the array? http://codepad.org/vaHOX8mW
>>5
I say newfag because I'm from /g/, not /b/.
And could you at least help me with the code?
I've got a C++ book and it looks like I'm doing it right I just don't know what I'm doing wrong. :s
Name:
Anonymous2011-01-13 4:21
Since nobody's responding other than screaming sage...
Can somebody link me to the programming board?
I must've gone to /b/ by accident.
Name:
Anonymous2011-01-13 4:23
/Silentlyawaitingreplies.jpg
Name:
Anonymous2011-01-13 4:26
>>1 int minimum(int A[], int length) {
int m = A[0];
for (int i = 0; i < length; i++) {
if (A[i] < m) {
m = A[i];
}
}
return m;
}
>>8
Why the fuck do you pass smallest as reference?
Why the fuck are you initialising it inside the function?
Why the fuck don't you return a value in a function (int[], int&) -> int)?
How the fuck do you know that the array will be of length 9?
If you know the length, why the fuck don't you make the function (int[9], int&) -> int so it will accepts just 9-elements arrays?
And WHAT THE FUCK IS THAT i + 1 INSIDE THE for LOOP?
int smallest(int *in, int length) {
int r = in[0], i;
for (i = 1; i < length; i++)
if (in[i] < r) r = in[i];
}
JesusChrist, don't they teach anything to kids these days‽
Sepples doesn't have type inference – why did you put that i + 1 in there? That turns the whole functor into a monomorphism (instead of the usual polymorphism which you undoubtedly have heard about when learning Sepples). Good luck with referential transparency now.
Why do you pass smallest as a reference? 1..n relations are terrible! practice.
Why the fixed loop iterations? Do you want to subject your code to a stack pointer monadic overflow?
YOu should rewrite your code after getting acquainted with the Sussman protocol, as defined in RFC (``Request for Cudders'') 6001.
Name:
Anonymous2011-01-13 4:36
>>15
I wouldn't expect me to be that good, I've been programming for a few days.
>>14
You're still an idiot and all of your posts do indeed suggest brain damage or any other mental deficiency.
Name:
Anonymous2011-01-13 4:38
>>17
Cool, all of the sage posts in every thread in this board seem to say that's common around here.
But if you're the guy that helped still thanks for it.
Please sage your shitty posts in the future. If you had any observational capabilities yo''u'd've' noticed that most posts at [spoiler/prog/[/spoiler] are saged.
Name:
Anonymous2011-01-13 4:40
>>21
Well the more you guys sage the more it makes me wanna reply. :3
>>24
1. Use fprintf ("fast printf") instead of printf. (recent studies revealed that the fastest printing function is vasprintf (the very accellerated sprintf)
2. ++i is faster than both i++ and i = i + 1.
3. void main(void) is faster than int main(void) or int main(int, char **) since no value needs to be returned to the OS.
4. Swapping with exclusive-or (a^=b^=a^=b swaps a and b) is faster than using a temporary. This works for all types (including structures), but not on all compilers. Some compilers may also give you a harmless warning.
5. Static storage duration objects are faster than automatic storage duration objects because the CPU doesn't have to set aside storage on the stack every time a function is called. Make your loop indexes global so that you can use them everywhere: int i;
void func(void) { for (i = 0; i < 10; i++) ; /* ... */ }
void func2(void) { for (i = 0; i < 20; i++) ; /* ... */ }
/* ... */
6. Compilers often give more memory to arrays than you asked for. Here's how to check how big an array actually is (memset returns a null pointer if the size you passed to it is bigger than the size of the array you passed to it): int arr[256];
size_t realsize;
for (realsize = 0; realsize <= SIZE_MAX; ++realsize)
if (!memset(arr, 0, realsize)) break;
/* now you know that arr actually has realsize / sizeof (int) elements */
If you combine this with #5, your program will be faster in the long run (but this usually doesn't work for short programs).
Some others:
(defun minimum (numbers) (apply #'min numbers)) ; works only with lists
(defun minimum (numbers) (reduce #'min numbers)) ; works with any sequence
Of course, #'min already performs OP's function, but it accepts a variable number of arguments instead of a list/vector/sequence.
>>42
Shouldn't the last case be (1 1.5 ...), unless I misunderstood what the intent of the code was, if given:
1 argument - generate a list from 0 to * given increments/steps of 1, so that you get "first argument" elements.
2 arguments - generate a list from "first argument" to "second argument" given increments/steps of 1
3 arguments - generate a list from "first argument" to "second argument" given increments/steps of "third argument".
Here's my attempt to write this in CL:
(defun seq (start-or-count &optional (end (1- start-or-count) end-present-p)
(by 1) &aux (start (if end-present-p start-or-count 0)))
(loop for i from start to end by by collect i))
Difference from your examples is that the third example is ran at compile-time as (+ 9 1) will be detected by my implementation as a constant (most implementations will do this, but they are not required by the standard to do it properly: how well a constant form will be detected depends on your implementation's own optimization code - CL merely gives access to this functionality, but only /recommends/ that compilers perform such optimizations).
And now I realized that a macro isn't really the recommended way to do this (when you have a function and a macro that are supposed to perform the same job, and the only reason you're also writing a macro is for optimization purposes, then you should use a compiler macro), thus the right definition is this:
(defun range (start-or-count &optional (end (1- start-or-count) end-present-p)
(by 1) &aux (start (if end-present-p start-or-count 0)))
(loop for i from start to end by by collect i))
(define-compiler-macro range (&rest args)
(if (every #'constantp args) `(list ,@(apply #'seq args)) `(seq ,@args)))
The only disadvantage to the macro version is that if you have a braindead implementation, it can refuse to run compiler macros, however if you have a braindead implementation, it might as well decide to not implement constantp for forms like (+ 1 (- 3 2). Either way, almost all major implementations support both of these just fine, so there's really no reason to worry (if you're running an implementation which doesn't support either of those, you've got other problems to worry about than this).
>>43
Oh, yes, I wrote that by hand, so I didn't notice, it produces (1 1.5 ... 4.5 5).
constantp
I wish Scheme had constant? too. It's not so difficult to implement, but it's boring and uninteresting.
>>44
Again, Scheme/Racket hasn't compiler macros, so if you have to optimise something (like, in this case, generating a list at compile-time), you have to write a macro.
I'm about to start learning CL, what compiler do you suggest me? Is SBCL a good choice (on Linux)?
>>46
SBCL is quite fine on Linux, it is the main implementation that I'm using, however I have my Emacs+SLIME set up so it can load a few other implementations that I have installed, this way I can test/compile my code with other implementations too (as long as I write it portably, if not, I tend to have to write a thin compatibility layer). Other free alternatives worth looking at are ClozureCL (OpenMCL), ECL, CMUCL (SBCL is a fork of this) and maybe CLISP. There's also a handful of decent commercial implementations (AllegroCL, Lisp-Works and Scieneer). If you desire portability to other platforms (Windows, *BSD, OS X, ...), some of those implementations support it (either fully or with some limitations: for example, SBCL's threading is only supported on Linux, however there are unofficial forks which add experimental support for it on other platforms).