 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible escreveu:
> * This is why, if a Haskell function takes any functions as arguments,
> they invariably come *first*, and any data structures come *last*. ;-)
Hmm, this is just a convention, I guess. There's no technical
limitation for a function not appearing last in the argument list.
> Yeah, looks like in about 8 years or so C# or Python or Ruby will have
> stolen everything that is cool about Haskell, and Haskell itself *still*
> won't be popular. :-(
>
> Which is a pitty, really, because few things can match the beauty and
> simplicity of Haskell...
Well, C# can because Microsoft employs the father of Haskell. ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford escreveu:
> Darren New wrote:
>> Errr, they are? No. A C++ thing, but not a C thing.
>
> Oh. For some reason I thought they were introduced in C.
huhuhu
C requires much more effort from a programmer aside from assembly... :P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> It's a saved stack, let's say.
Uh, no. It's an object. A stack is LIFO, for one thing.
It's a stack only in the sense that if you pass a bunch of parameters to a
function, the function gets a pointer to where they are contiguous in memory
when you invoke the function, not unlike invoking a member method.
> I don't like the whole OO BS. Despite being submitted to it daily for
> the last 20 years or so. Functional programming and scripting too
> opened my eyes to a much better model for software programming.
Yah. It's handy for some things, like where OO is natural. It can be
annoying to try to squeeze functional stuff (like, say, the relational
model) into an OO framework. Most of my code is still procedural, and most
OO code I see (in things like web page servers etc) really doesn't need to
be OO anyway.
--
Darren New, San Diego CA, USA (PST)
"Ouch ouch ouch!"
"What's wrong? Noodles too hot?"
"No, I have Chopstick Tunnel Syndrome."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Mike Raiford <"m[raiford]!at"@gmail.com> wrote:
>> At least in C# you can't do function pointers.
>
> There are situations where function pointers are actually useful.
> Here's one actual example which I have used in the past (simplified here,
> of course):
>
> class MyCLP: public CommandLineParser
> {
> bool debugParamHandler(const std::string&)
> {
> // do whatever here
> }
>
> public:
> MyCLP()
> {
> setOptionHandler("debug", &MyCLP::debugParamHandler,
> "The short description of the -debug parameter");
> }
> };
>
C# uses delegates, instead. Similar functionality Not as ugly to
declare. Function pointer syntax can get ugly.
>
> std::sort(array.begin(), array.end(), objectComparator);
>
Again, very similar to the predicates used in C#'s extension functions,
which take delegates.
>
> It's possible to create an object which behaves like such a function
> (a functor object), but it's more writing.
>
Which is essentially a delegate :)
I was mainly alluding to the messiness of declaring function pointers.
C# does have a mechanism to do what you've described, though.
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> xyz += foofoo;
>
> Then when you call
> xyz(71.3);
> it passes 71.3 to doodoo then to foofoo.
>
> Less helpful if you actually need the results, but often delegates are
> used as things like callbacks for user interface frobbings or other
> async events, so failures tend to be propagated back as exceptions
> rather than return results.
What is the difference between a multicast delegate, as shown here, and
an event?
Love the function names, btw..
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> Mike Raiford escreveu:
>> Darren New wrote:
>>> Errr, they are? No. A C++ thing, but not a C thing.
>>
>> Oh. For some reason I thought they were introduced in C.
>
> huhuhu
>
> C requires much more effort from a programmer aside from assembly... :P
Considering I started with C++, It's easy for me to blur the lines,
sometimes. I remember declaring structs in C being rather weird.
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] san rrcom> wrote:
> I think better would be the way you wind up having to do it in Java - you
> have a class that implements a "parse this" method for each possible
> argument to be parsed, and the parser has a map from "-debug" to an instance
> of the class that parses the debug parameter. So you have one subclass for
> each parser function. Ugly, but not as bad as a giant switch statement.
Actually that's the most cumbersome solution (especially if you wanted
all the options inside one single class, rather than having one class per
option, which makes retrieving the values of the options more laborious)
and the one which requires most extra writing.
Yes, I considered many possible solutions when I implemented that command
line parser class, and found that the function (or rather method) pointer
solution was the best, from the usage point of view. The classes derived
from the parser class can be made simple, short and easy to read.
> FWIW, a delegate *is* an object that behaves like a function (your "functor
> object"). You write something like
Does it also work for member functions?
Member function pointers are a bit complicated in C++, but they can
be useful (as in my command line parser example). Obviously to call a
member function of a class through a pointer you need also the object for
which the function is called. The syntax for calling such a function is:
object.*functionPointer(parameters);
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford <"m[raiford]!at"@gmail.com> wrote:
> C# uses delegates, instead.
How do they work for member functions?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford <"m[raiford]!at"@gmail.com> wrote:
> I remember declaring structs in C being rather weird.
The problem with C structs is that whenever you want to use them, you
have to say so. In other words, this works in C++, but not in C:
struct Foo { whatever; };
void bar()
{
Foo foo; // Doesn't work in C
}
Instead, you have to write:
struct Foo foo; // Works in both C++ and C
However, there's a workaround in C (which also works in C++, because of
the backwards compatiblity):
typedef struct { whatever; } Foo;
Now you can use "Foo" without having to put the "struct" before it every
time.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis <nam### [at] gmailcom> wrote:
> I don't like the whole OO BS. Despite being submitted to it daily for
> the last 20 years or so. Functional programming and scripting too
> opened my eyes to a much better model for software programming.
Yet most functional programming languages support objects in one way
or another.
The fact is: If a programming language supports types, if it also
supports abstract user-defined types, it becomes an order of magnitude
more expressive and useful. And abstract user-defined types are objects
(in the OO sense).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
