clearly not? lol

Would this be a problem relating to operator overloading?

Write the following expression in point-free form:

Haskell:

f n = g (x n) (y n)

Write the following expression in point-free form:

Haskell:

f n = g (x n) (y n)

Hey! Congrats and welcome to compsci!

BTW: There is no need for you to redefine any of the Prelude functions (flip, composition). I was hoping you could do it without defining any of your own functions, like twice.

The truth is, that is not the answer I was hoping for, but it is an answer I was expecting -- or one kind of answer anyway. You get 350 bits for that one
<snip>
Eitherway, this is still not what I'm looking for, for that extra 150bits.

No. Let me give you a hint: I'm looking for a simpler solution
Another hint: (->a)

We had one Turing TYS (of sorts) a while back: http://www.compsci.ca/v2/viewtopic.php?t=10450

Another C++ TYS.

Another C++ TYS.

code:

#include <iostream> #include <string> #include <algorithm> #include <iterator> using namespace std; int main() {    string foo[] = {"Hello", "world"};    print_all(foo);    return 0; }

Make this work, such that the output is:

code:

Hello world

You may not use "sizeof" or hard-code the size of the array. In other words, it must still work if the size of the array changes.

It must also work if the type of the array is changed. For instance, if foo were an array of five integers.

Bonus points if the body of the print_all function is only one line long.

Another C++ TYS.

code:

#include <iostream> #include <string> #include <algorithm> #include <iterator> using namespace std; int main() {    string foo[] = {"Hello", "world"};    print_all(foo);    return 0; }

Make this work, such that the output is:

code:

Hello world

You may not use "sizeof" or hard-code the size of the array. In other words, it must still work if the size of the array changes.

It must also work if the type of the array is changed. For instance, if foo were an array of five integers.

Bonus points if the body of the print_all function is only one line long.

C++ today.

code:

#include <iostream> #include <string> #include <algorithm> using namespace std; char upcase(const char original); string capitalize(const string& s); int main(int argc, char **argv) {    string *args = new string[argc - 1];    copy(argv + 1, argv + argc, args);    transform(args, args + argc - 1, args, capitalize);    for (int i = 0; i < argc - 1; i++)    {       cout << i << " " << args[i] << endl;    }    delete args;    return 0; } char upcase(const char ch) {    return (ch >= 97 && ch <= 122) ? ch - 32 : ch; } string capitalize(const string& s) {    string dup = s;    if (dup.length() > 0)    {       dup[0] = upcase(dup[0]);    }    return dup; }

I have done something wrong here. Find and explain the mistake.

Just about. Though that for loop should really be two lines.

Here's wtd's solution:

c++:

#include <iostream> #include <string> #include <algorithm> #include <iterator>   using namespace std;   template <typename T, size_t N> void print_all(T (&arr)[N]) {    copy(arr, arr + N, ostream_iterator<T>(cout, "\n")); }   int main() {    string foo[] = {"Hello", "world"};    print_all(foo);    return 0; }

Some crazy code, I must say.

dump the contents of the array into the vector, and use iterators to access them?

That was my original guess as well, but how would you "dump the contents of the array into a vector" under these circumstances?

Aziz, why do that when arrays already keep track of their size in Java? Just use o.length.

You may not use "sizeof" or hard-code the size of the array. In other words, it must still work if the size of the array changes.

The obvious one is:

code:

delete args;

which should be

code:

delete[] args;

.

I am not so clear about the explanation though, so here is my try at it:
argc can be 1;
args can point to a zero-length array and be distinct from a pointer to any other object;
using "plain" delete on args in such a case causes undefined behaviour (afaik).

I suspect that

code:

args + argc - 1

is also a cause of undefined behaviour when argc is 1.

code:

args + argc - 1

This is simply pointer arithmetic. If argc is one, then one minus one is zero, and we get the same args pointer back.

The result of

code:

args + argc

is undefined, afaik.

To get what you want, you need

code:

args + (argc - 1)

It is not undefined.

args is a pointer. argc is an integer, as is "argc - 1". Adding a pointer and an integer is not undefined. It is in fact the way array access works.

code:

args[n]

Is equivalent to:

code:

*(args + n)

It only produces undefined behavior if you dereference it. My code never does that. :)

And all I need to do is go one past the end of the array, so that I have a known sentinel value.

Ok... I think you're missing something here.

Pointers are just numbers. Within the range of that integer type, I can assign any value I want to a pointer. As long as I don't dereference it, there's no problem.

Trying to follow to question as much as possible...

As far I can tell, the standard specifies only that any of this becomes an issue when dereferencing is brought into question. Comparing the value of two pointers does not entail any dereferencing operation(s).

If you know of a section of the standard that specifies otherwise, please enlighten me.

If "enum" is being used in reference to all integral types, then pointer arithmetic is smply outright undefined behavior in all forms.

Can you provide an exact quotation for what you're looking at?

When an expression that has integral type is added to or subtracted
from a pointer, the result has the type of the pointer operand. If
the pointer operand points to an element of an array object, and the
array is large enough, the result points to an element offset from the
original element such that the difference of the subscripts of the
resulting and original array elements equals the integral expression.
In other words, if the expression P points to the i-th element of an
array object, the expressions (P)+N (equivalently, N+(P)) and (P)-N
(where N has the value n) point to, respectively, the i+n-th and i-n-
th elements of the array object, provided they exist. Moreover, if
the expression P points to the last element of an array object, the
expression (P)+1 points one past the last element of the array object,
and if the expression Q points one past the last element of an array
object, the expression (Q)-1 points to the last element of the array
object. If both the pointer operand and the result point to elements
of the same array object, or one past the last element of the array
object, the evaluation shall not produce an overflow; otherwise, the
behavior is undefined.

Gracias.

Interesting. Of course, having the ability to go one past the end suffices for pretty much any foreseeable scenario.