 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime wrote:
> Man, I'm in the wrong time zone. You always get to answer the questions
> first! =)
Which timezone is that then?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> (You knew there were going to be a few at some point...)
>
> I just want to make sure I've got this absolutely straight in my head.
> So... a reference is the same as a pointer, except that it has nicer
> syntax, and you cannot change where it points to?
>
> If I'm understanding this correctly, a "union" is like several structs
> with the same base address, and you can treat it was one struct or the
> other struct, and it's up to you to remember which which struct you're
> currently using it is. (I.e., the language itself provides no way to
> distinguish.)
>
> Here's a perverse question: can a union have member functions?
Yes.
> My understanding is that when you create variables, they start off
> containing junk unless you initialise them (or their types have
> constructors which initialise them to something specific). Is that correct?
Yes.
> Does C++ have a concept of a "null pointer" - i.e., a pointer that
> doesn't point to anything valid, and can be detected as such?
Yes.
> How does memory allocation work in C++? If a program fills the heap, do
> you have to explicitly *do* something to enlarge the heap, or does it
> grow automatically? Does it shrink back again after you release things,
> or do you have to request that manually?
Depends on the implementation.
Regards,
John
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime wrote:
>> More exactly, in C at least, any variables allocated statically start with
>> a default value of zero appropriate for their type. That includes static
>> variables allocated inside a function.
>
>
> I was under the impression that global variables are initialized to zero,
> but you can't trust local variables because the stack has whatever garbage
> data was left on it from previously called functions.
Correct. I was also pointing out that they get initialized to the type's
version of zero, whatever that might be. (I.e., pointers may not have
all zero bits in them; they get initialized to null instead.) Rarely can
you see this difference. :-)
And variables that are static but not global also get initialized.
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] san rrcom> wrote:
> Correct. I was also pointing out that they get initialized to the type's
> version of zero, whatever that might be. (I.e., pointers may not have
> all zero bits in them; they get initialized to null instead.) Rarely can
> you see this difference. :-)
Actually it's possible to invoke the "default initialization" for any
type at any point in C++. For example if you do this:
int i = int();
the 'i' variable will be default-initialized with the "zero" value for
the type in question (which, in this case, is the integer 0).
One might ask what's the point. It's actually useful when you don't
know what the type actually is. This happens eg. with templates. You
could have, for example, this:
template<typename Type>
void foo()
{
Type i = Type(); // Default-initialize i, even if it's a basic type
...
}
Although mostly it's useful in situations where you want to create a
default-initialized temporary, for example in code like this:
someVector.push_back(Type());
That will work even if 'Type' is an int, a double or a pointer.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Which timezone is that then?
PST. (California.)
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime wrote:
>> Which timezone is that then?
>
> PST. (California.)
You're Californian?
Wow... suddenly a whole lot of POV-Ray stuff makes way more sense... ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Copy...constructor...? x_x
Heh. And I thought figurating out the difference between a const pointer
and a pointer to a const was hard!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Copy...constructor...? x_x
Pointers to members?
OK, maybe I should stop reading now. :-/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> Copy...constructor...? x_x
Usually you don't need copy constructors unless you have pointers as
member variables of your class and you explicitly allocate memory to
them with 'new'. But we don't do that, do we? ;)
If you want a quick crash course on copy constructing when the class
allocates memory explicitly, check this:
http://warp.povusers.org/c++test/
(There are actually a few other situations where a copy constructor is
mandatory for a class to work properly, but they are slightly advanced
stuff.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> Pointers to members?
You don't need them.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> Pointers to members?
>
> You don't need them.
That's what I was pretty much hoping, yeah.
Looks like it would only be useful for some pretty obscure situations...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> Copy...constructor...? x_x
>
> Usually you don't need copy constructors unless you have pointers as
> member variables of your class and you explicitly allocate memory to
> them with 'new'. But we don't do that, do we? ;)
Heh. I get the impression that most of the stuff I'm reading about now
is stuff that "you won't normally need". ;-)
(E.g., apparently you can overload the "->" operator... GAH! >_< OK, I
am *so* not trying that out!)
Anyway, the main reason I haven't written a Third C++ Program yet is
that I'm trying to think of something I actually want to write that's
implementable without automatic memory management...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> Warp wrote:
> > Invisible <voi### [at] devnull> wrote:
> >> Pointers to members?
> >
> > You don't need them.
> That's what I was pretty much hoping, yeah.
> Looks like it would only be useful for some pretty obscure situations...
They are useful in certain situations, but those situations are so rare
and usually so advanced, that even very experienced C++ programmers basically
never need them.
I once created a command-line parameter interpreter which was used like
this (extremely simplified):
class MyCLI: public CommandLineInterpreter
{
void inputFile() { ... }
public:
MyCLI()
{
// registerCLParameter() is a function in the base class.
registerCLParameter("input", &inputFile);
}
};
Basically this meant that when the interpreter encountered the command-line
parameter "-input", it would call the 'inputFile()' method I defined above.
This uses method pointers.
(The actual implementation is quite complicated because there are some
issues about a base class calling a derived class method through a method
pointer, but with template magic it's possible to do this portably and
safely.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> Warp wrote:
> > Invisible <voi### [at] devnull> wrote:
> >> Copy...constructor...? x_x
> >
> > Usually you don't need copy constructors unless you have pointers as
> > member variables of your class and you explicitly allocate memory to
> > them with 'new'. But we don't do that, do we? ;)
> Heh. I get the impression that most of the stuff I'm reading about now
> is stuff that "you won't normally need". ;-)
It's not like you don't need copy constructors (and copy assignment).
It's just that a beginner doesn't usually need them. When you start needing
copy constructors, your code will be a bit more advanced.
> (E.g., apparently you can overload the "->" operator... GAH! >_< OK, I
> am *so* not trying that out!)
You can overload almost any operator, including 'new' (it's considered
an operator in C++) and the prefix-&.
I think the only operator you can't overload is the dot operator.
> Anyway, the main reason I haven't written a Third C++ Program yet is
> that I'm trying to think of something I actually want to write that's
> implementable without automatic memory management...
Hmm, is that sentence correct? Everything is implementable without
automatic memory management. Perhaps you meant something else?-)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Heh. I get the impression that most of the stuff I'm reading about now
>> is stuff that "you won't normally need". ;-)
>
> It's not like you don't need copy constructors (and copy assignment).
> It's just that a beginner doesn't usually need them. When you start needing
> copy constructors, your code will be a bit more advanced.
Well, yeah. And *I* am unlikely to be writing anything "advanced" any
time soon! ;-)
>> (E.g., apparently you can overload the "->" operator... GAH! >_< OK, I
>> am *so* not trying that out!)
>
> You can overload almost any operator, including 'new' (it's considered
> an operator in C++) and the prefix-&.
>
> I think the only operator you can't overload is the dot operator.
And .* (apparently).
Also, unlike Haskell, you apparently can't make up new operators of your
own, just overload the ones that already exist.
>> Anyway, the main reason I haven't written a Third C++ Program yet is
>> that I'm trying to think of something I actually want to write that's
>> implementable without automatic memory management...
>
> Hmm, is that sentence correct? Everything is implementable without
> automatic memory management. Perhaps you meant something else?-)
Well, yeah, but it's a touch harder to implement heap-allocated data in
such a way that your program doesn't leak like a sieve. ;-)
[I'm actually surprised that using std::vector doesn't do this already...]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> Also, unlike Haskell, you apparently can't make up new operators of your
> own, just overload the ones that already exist.
Aren't C++ compilers already stressed enough? Think about all the problems
they would have with user-defined operators, with their own precedence
rules, ambiguous situations, etc... :P
> Well, yeah, but it's a touch harder to implement heap-allocated data in
> such a way that your program doesn't leak like a sieve. ;-)
You usually use the STL data containers for dynamically allocated
memory, and if what you need is to allocate a single object, you can
use a smart pointer (I posted in the other group an URL to one smart
pointer implementation I have made).
> [I'm actually surprised that using std::vector doesn't do this already...]
Doesn't do what?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Also, unlike Haskell, you apparently can't make up new operators of your
>> own, just overload the ones that already exist.
>
> Aren't C++ compilers already stressed enough? Think about all the problems
> they would have with user-defined operators, with their own precedence
> rules, ambiguous situations, etc... :P
Heh, yeah... I can see that. ;-)
>> Well, yeah, but it's a touch harder to implement heap-allocated data in
>> such a way that your program doesn't leak like a sieve. ;-)
>
> You usually use the STL data containers for dynamically allocated
> memory, and if what you need is to allocate a single object, you can
> use a smart pointer.
Fair enough.
>> [I'm actually surprised that using std::vector doesn't do this already...]
>
> Doesn't do what?
Leak like a sieve! ;-)
I've never actually seen a programming environment with manual memory
management *and* dynamically resizable collections. The two are usually
muturally exclusive.
Then again, I'm not really sure what the story is if you try to put
user-defined data types into a vector...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
>
> (E.g., apparently you can overload the "->" operator... GAH! >_< OK, I
> am *so* not trying that out!)
>
Useful for the "Smart Pointer" pattern. The autogen stuff for COM uses
these a lot.
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> >> [I'm actually surprised that using std::vector doesn't do this already...]
> >
> > Doesn't do what?
> Leak like a sieve! ;-)
The class constructors, assignment and destructor help in automatizing
the internal memory management of the vector.
You can write your own dynamic data container as a class in the exact
same way as std::vector and the other STL containers, which will be safe
and will automatically manage its memory.
And not only memory. There are also other resources which can be
automatically managed with classes. Consider this:
void foo()
{
std::ofstream os("outfile.txt");
os << "Hello\n";
bar();
os << "there.\n";
}
Note that nowhere is the file actually explicitly *closed*. However,
no open file handles are leaked because it gets closed automatically
because the std::ofstream class handles this resource.
This is even so even if the function is exited abnormally. For example,
assume that the bar() call throws an exception. If that happens, the
function will be exited immediately (before the "there.\n" string is
written to the file). This is "unexpected" and we didn't take that
possibility into account. However, it doesn't matter: The file will
still be closed and thus no resource leak happens.
Unless I'm completely mistaken, this is not something you can achieve
in Java. (In Java you have to close files explicitly and catch all
possible exceptions which might otherwise bypass that closing.)
> I've never actually seen a programming environment with manual memory
> management *and* dynamically resizable collections. The two are usually
> muturally exclusive.
Well, it's not like *all* resources in C++ are managed manually.
More precisely, stack-allocated objects are managed automatically. Which
is exactly the reason why automatic management heap-allocated objects
becomes possible through these stack-allocated objects.
> Then again, I'm not really sure what the story is if you try to put
> user-defined data types into a vector...
If the user-defined type doesn't allocate memory in itself, or if it
does but manages it properly, there shouldn't be any problems.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford <"m[raiford]!at"@gmail.com> wrote:
> Invisible wrote:
> > (E.g., apparently you can overload the "->" operator... GAH! >_< OK, I
> > am *so* not trying that out!)
> >
> Useful for the "Smart Pointer" pattern. The autogen stuff for COM uses
> these a lot.
Also used with iterators. (An iterator is an object which behaves
like a pointer.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> The class constructors, assignment and destructor help in automatizing
> the internal memory management of the vector.
>
> You can write your own dynamic data container as a class in the exact
> same way as std::vector and the other STL containers, which will be safe
> and will automatically manage its memory.
But presumable you'd need to know what you're doing first. ;-)
> And not only memory. There are also other resources which can be
> automatically managed with classes.
Mmm, that's nice.
> Unless I'm completely mistaken, this is not something you can achieve
> in Java. (In Java you have to close files explicitly and catch all
> possible exceptions which might otherwise bypass that closing.)
Actually, for reasons beyond my comprehension, if a Haskell program
halts abnormally, all files are closed, but not necessarily *flushed*.
Like, WTF? *Why?* Anyway, basically you have to write some code to catch
the exception and close the file before rethrowing it. It's an extra 3
lines of code, but you still have to remember to type them...
>> I've never actually seen a programming environment with manual memory
>> management *and* dynamically resizable collections. The two are usually
>> muturally exclusive.
>
> Well, it's not like *all* resources in C++ are managed manually.
> More precisely, stack-allocated objects are managed automatically. Which
> is exactly the reason why automatic management heap-allocated objects
> becomes possible through these stack-allocated objects.
Indeed. I've not seen this in any other OO language.
>> Then again, I'm not really sure what the story is if you try to put
>> user-defined data types into a vector...
>
> If the user-defined type doesn't allocate memory in itself, or if it
> does but manages it properly, there shouldn't be any problems.
Sounds good to me! ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Looks like it would only be useful for some pretty obscure situations...
Really? They're useful all the time in C#. Like, every time you have a
callback function you register with the GUI, or every time in Java where
you'd have to create an anonymous inner class or something. Pointers to
members are the OO mechanism corresponding to closures.
You have a window representing an object. You want to be notified
whenever the mouse moves over the window. How do you tell the window
manager that?
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Unless I'm completely mistaken, this is not something you can achieve
> in Java. (In Java you have to close files explicitly and catch all
> possible exceptions which might otherwise bypass that closing.)
The destructor will close the file when the GC collects the object, but
that might be several seconds later. And it might not run if you exit
the program before the GC runs, but that's true of C++ also. So it's not
quite as nicely deterministic, but it still happens eventually.
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Actually, for reasons beyond my comprehension, if a Haskell program
> halts abnormally, all files are closed, but not necessarily *flushed*.
Because it's Haskell that flushes the buffers to the file, but it's the
OS that closes the file. If you run it on (say) an Amiga, it won't close
the files, either. Apparently Haskell isn't writing directly to the
files, but to Haskell-managed buffers. Same thing happens in C with stdio.
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
>
> The destructor will close the file when the GC collects the object, but
> that might be several seconds later. And it might not run if you exit
> the program before the GC runs, but that's true of C++ also. So it's not
> quite as nicely deterministic, but it still happens eventually.
>
C# has the same issue. You can sort of work around it with the using
statement, which will call Dispose on an IDisposable object, which, in
turn, closes the file.
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford wrote:
> Darren New wrote:
>
>>
>> The destructor will close the file when the GC collects the object,
>> but that might be several seconds later. And it might not run if you
>> exit the program before the GC runs, but that's true of C++ also. So
>> it's not quite as nicely deterministic, but it still happens eventually.
>>
>
> C# has the same issue. You can sort of work around it with the using
> statement, which will call Dispose on an IDisposable object, which, in
> turn, closes the file.
Yep. Of course, it's really not a problem in a system where the kernel
participates in the GC, like Singularity does.
And, really, memory is a huge percentage of the resources you manage, so
the small bit of "real" resources you have to handle manually is usually
not much of a problem. Indeed, only once did I have code sufficiently
convoluted and error-prone that I had a resource leak of this type in
Tcl. And even then, it's because I wrote the code poorly and instead of
(say) wrapping the allocation and use in a procedure call, I tried to
handle it all inline.
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Invisible wrote:
>> Actually, for reasons beyond my comprehension, if a Haskell program
>> halts abnormally, all files are closed, but not necessarily *flushed*.
>
> Because it's Haskell that flushes the buffers to the file, but it's the
> OS that closes the file. If you run it on (say) an Amiga, it won't close
> the files, either. Apparently Haskell isn't writing directly to the
> files, but to Haskell-managed buffers. Same thing happens in C with stdio.
Yeah, but if the Haskell runtime has code to handle printing out a
human-readable error message on an unhandled exception, why can't it
also run some finalisers? This is pretty basic stuff!
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 26 Sep 2008 16:30:35 +0200, Invisible <voi### [at] devnull> wrote:
>> I think the only operator you can't overload is the dot operator.
>
> And .* (apparently).
:: and ?: cannot be overloaded either.
--
FE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Invisible wrote:
> > Looks like it would only be useful for some pretty obscure situations...
> Really? They're useful all the time in C#. Like, every time you have a
> callback function you register with the GUI, or every time in Java where
> you'd have to create an anonymous inner class or something. Pointers to
> members are the OO mechanism corresponding to closures.
> You have a window representing an object. You want to be notified
> whenever the mouse moves over the window. How do you tell the window
> manager that?
Isn't this usually handled with callback interfaces (in OO languages)
rather than function pointers?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fredrik Eriksson wrote:
> On Fri, 26 Sep 2008 16:30:35 +0200, Invisible <voi### [at] devnull> wrote:
>>> I think the only operator you can't overload is the dot operator.
>>
>> And .* (apparently).
>
> :: and ?: cannot be overloaded either.
That seems logical...
I bet you can't overload ";", can you? In Haskell, you can. >:-D
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Isn't this usually handled with callback interfaces (in OO languages)
> rather than function pointers?
Speaking of which... apparently you can overload "()", thus creating an
object that looks like a function... How far-out is that? o_O
I'm almost tempted to try just to see if I can implement curried
functions with it in C++. You know, just to be totally perverse...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > Unless I'm completely mistaken, this is not something you can achieve
> > in Java. (In Java you have to close files explicitly and catch all
> > possible exceptions which might otherwise bypass that closing.)
> The destructor will close the file when the GC collects the object, but
> that might be several seconds later.
I don't know how it is today, but at least in the past the amount of
file handles one single program could keep open at the same time was
ridiculously limited (IIRC to a few dozens or so). If the program tried
to open more than that, it would fail.
If a program is constantly opening files, doing something to them, and
then closing them, a file handle leak (which would happen if it fails to
close them for some reason, eg. because of a bug or a suprising exception)
can cause the program to malfunction. And this might not be caught on
testing, if the testing fails to stress the program in the same way as
it happens in actual usage...
OTOH, I could imagine that if Java detects that a file cannot be opened
because of too many file handles being open, it could automatically try
to run the GC and then try again.
OTOH, file handles are just *one* possible resource which can leak.
Java can't be prepared for all of them.
> And it might not run if you exit
> the program before the GC runs, but that's true of C++ also.
It's true of C++ only if your stream has been allocated dynamically
(directly or indirectly). If it's stack-allocated then there's no way
its destructor won't be called.
(Ok, there is a way: If you call abort() the program is immediately
terminated without any stack unwinding, in which case no destructors
are called at all. However, abort() is such a harsh way of terminating
the program that it shouldn't happen in normal code.
Incidentally a failed assert() calls abort(), which is the reason why
assert() should only be used to catch programming errors, not to exit
the program normally.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 26 Sep 2008 19:44:56 +0200, Orchid XP v8 <voi### [at] devnull> wrote:
>
> I bet you can't overload ";", can you?
';' is not an operator. It is a statement terminator. It would make no
sense for a C++ program to redefine the meaning of ';'.
> In Haskell, you can. >:-D
Can you overload/redefine '->' in Haskell? What about '()'?
--
FE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> Warp wrote:
> > Isn't this usually handled with callback interfaces (in OO languages)
> > rather than function pointers?
> Speaking of which... apparently you can overload "()", thus creating an
> object that looks like a function... How far-out is that? o_O
So-called functors are a common idiom in C++ template programming.
For example many STL data containers and algorithms accept functors
as parameters.
A functor is something which acts like a function. In other words, it
can be called like a function can be called, and it will return a value
like a function returns a value.
Obviously a regular function is a valid functor (and a common way to
pass functors to the STL).
Another way of creating a functor is, as you point out, to create a
struct or class which has the operator() overloaded. This way an instance
of that class can be used exactly like it was a function.
The advantage of the latter method is that the struct/class can have
member variables (and member functions) which the operator() can use.
This way you can have different values for those member variables for
different instances of the functor. (If I'm not completely mistaken,
this starts get closer to so-called closures.)
In the next C++ standard there will be a third type of functor: Lambda
functions.
> I'm almost tempted to try just to see if I can implement curried
> functions with it in C++. You know, just to be totally perverse...
C++ might not be the best language for that... ;)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> I bet you can't overload ";", can you? In Haskell, you can. >:-D
; is not an operator in the first place.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I bet you can't overload ";", can you?
>
> ';' is not an operator. It is a statement terminator.
Yes, I know that. ;-) I was just being silly...
>> In Haskell, you can. >:-D
>
> Can you overload/redefine '->' in Haskell?
No. But then, it means something different in Haskell anyway.
> What about '()'?
No.
But then, in Haskell, a function *is* a data value, so there's not so
much need...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I bet you can't overload ";", can you? In Haskell, you can. >:-D
>
> ; is not an operator in the first place.
Yeah, I know that. ;-) I'm just teasing.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> So-called functors are a common idiom in C++ template programming.
> For example many STL data containers and algorithms accept functors
> as parameters.
>
> A functor is something which acts like a function. In other words, it
> can be called like a function can be called, and it will return a value
> like a function returns a value.
>
> Obviously a regular function is a valid functor (and a common way to
> pass functors to the STL).
I see...
> Another way of creating a functor is, as you point out, to create a
> struct or class which has the operator() overloaded. This way an instance
> of that class can be used exactly like it was a function.
>
> The advantage of the latter method is that the struct/class can have
> member variables (and member functions) which the operator() can use.
> This way you can have different values for those member variables for
> different instances of the functor. (If I'm not completely mistaken,
> this starts get closer to so-called closures.)
Yes, indeed. It looks like that means you could do something like write
a struct that contains a number, and make it into a functor that adds
that number when called. OTOH, if your function really had to be a
*function*, you'd have to write a seperate function for every value you
might want to add... which would be, uh, silly.
In Haskell, you can just say "map (*2)" and it'll work. It looks like
what you're describing enables you to achieve something very similar in C++.
(Presumably the *other* thing about a C++ functor is that it could
change some internal state each time you call it - say, to generate
unique IDs or something...?)
> In the next C++ standard there will be a third type of functor: Lambda
> functions.
Knowing what I now know about C++ (constructors, copy constructors,
assignment constructors, pointers, references, etc.), I suspect this is
going to be... uh... "interesting". :-}
I wonder what the scoping rules would be like?
>> I'm almost tempted to try just to see if I can implement curried
>> functions with it in C++. You know, just to be totally perverse...
>
> C++ might not be the best language for that... ;)
Heh. It could probably work... but no, I'm sure it'll be pretty ugly.
;-) [Not to mention being abnormal C++ style.]
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> I bet you can't overload ";", can you? In Haskell, you can. >:-D
>>
>> ; is not an operator in the first place.
>
> Yeah, I know that. ;-) I'm just teasing.
Wow, wait a sec...
http://www.research.att.com/~bs/whitespace98.pdf
WTF?! O_O
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> Wow, wait a sec...
> http://www.research.att.com/~bs/whitespace98.pdf
> WTF?! O_O
I think that paper is a joke.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> I think that paper is a joke.
I really, *really* hope you're right about that...
Especially the use of multicoloured identifiers, and the use of dingbats
as names!
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Isn't this usually handled with callback interfaces (in OO languages)
> rather than function pointers?
Only in languages that don't support pointers to member functions. In
languages with closures or pointers to member functions, no. Just like
in a language without pointers at all, the way you do callbacks is to
redefine the function at link-time and then do a big switch statement.
C#, for example, has the "observer" design pattern built into the
language as "delegates" or "events", accepting multiple pointers to
member functions and letting the owner "invoke" all the methods pointed to.
Ruby and Smalltalk and all those pass around "blocks" for this
functionality. Python passes around lambdas. LISP passes around
closures. They're all essentially the same sort of thing, with ever so
slightly different implementations, but all basically "a block of code
with a pointer to an object's context".
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> Yeah, but if the Haskell runtime has code to handle printing out a
> human-readable error message on an unhandled exception, why can't it
> also run some finalisers? This is pretty basic stuff!
Yep, true. I didn't realize you meant "exited cleanly due to an
unhandled exception." I thought you meant "crashed out due to a signal,
or running out of memory, or some such."
I suppose you could theoretically do a final GC and finalize before you
exited (but perhaps before you printed the exception stack?), but I
think at that point you're already pretty screwed. :-)
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> I don't know how it is today,
Usually a thousand or so, where such things are actually limited by
something other than the amount of memory available.
> If a program is constantly opening files, doing something to them, and
> then closing them, a file handle leak (which would happen if it fails to
> close them for some reason, eg. because of a bug or a suprising exception)
> can cause the program to malfunction. And this might not be caught on
> testing, if the testing fails to stress the program in the same way as
> it happens in actual usage...
Yep. That's exactly what was happening to me in my Tcl code. When I
could get the socket connection but it failed before it finished
flushing the first buffer, I failed to close the socket. After a couple
weeks of running, the program would bomb out with a file handle leak.
That was very annoying to debug. I probably should have just tossed that
whole function and started over.
> OTOH, I could imagine that if Java detects that a file cannot be opened
> because of too many file handles being open, it could automatically try
> to run the GC and then try again.
It could. That's what I like to recommend, but oddly few language
designers listen to me. >8)
> OTOH, file handles are just *one* possible resource which can leak.
> Java can't be prepared for all of them.
Well, it knows when something fails due to a lack of resources. It's
even not unreasonable that (for example) opening a file could fail from
lack of memory to put the stdio buffer in, or something, in which case a
GC and a retry could correct it.
>> And it might not run if you exit
>> the program before the GC runs, but that's true of C++ also.
>
> It's true of C++ only if your stream has been allocated dynamically
> (directly or indirectly). If it's stack-allocated then there's no way
> its destructor won't be called.
Yeah. And a sufficiently smart compiler for Java or whatever could do
escape analysis, see that the stream isn't used outside the function,
and stack allocate it and explicitly clean it up afterwards. Not that
compilers quite do that yet.
> (Ok, there is a way: If you call abort() the program is immediately
> terminated without any stack unwinding, in which case no destructors
> are called at all. However, abort() is such a harsh way of terminating
> the program that it shouldn't happen in normal code.
That's what I was talking about, yes. I thought Andrew was referring to
exiting Haskell with a core dump, basically, rather than simply an
exception caught at the top level.
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Yeah, but if the Haskell runtime has code to handle printing out a
>> human-readable error message on an unhandled exception, why can't it
>> also run some finalisers? This is pretty basic stuff!
>
> Yep, true. I didn't realize you meant "exited cleanly due to an
> unhandled exception." I thought you meant "crashed out due to a signal,
> or running out of memory, or some such."
>
> I suppose you could theoretically do a final GC and finalize before you
> exited (but perhaps before you printed the exception stack?), but I
> think at that point you're already pretty screwed. :-)
Basically, all you have to do is write a Haskell program that calls the
"error" function somewhere, and your program will exit without closing
anything behind it. Unless *you* remembered to take steps to prevent that.
That seems... a little unsafe to me.
Still, at least the code to do it isn't that hard.
bracket
(openFile "Foo.txt" ReadMode)
(hClose)
(\file_handle -> ...do stuff...)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> Warp wrote:
>
>> I think that paper is a joke.
>
> I really, *really* hope you're right about that...
""
Because this project relies of the ability
to fool the brain into accepting a projected image as 3D and because we
don't take delivery of the 3D
projection device until next spring, this project is usually referred to
as "Project April Fool."
""
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > Isn't this usually handled with callback interfaces (in OO languages)
> > rather than function pointers?
> Only in languages that don't support pointers to member functions.
C++ supports pointers to member functions, yet using callback interfaces
is a rather common idiom.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> ""
> Because this project relies of the ability
> to fool the brain into accepting a projected image as 3D and because we
> don't take delivery of the 3D
> projection device until next spring, this project is usually referred to
> as "Project April Fool."
> ""
Oh thank *God*!
Damn, he writes so convincingly...
[...says the guy who mistakenly took HGTTG seriously! o_O ]
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Warp wrote:
>>> Isn't this usually handled with callback interfaces (in OO languages)
>>> rather than function pointers?
>
>> Only in languages that don't support pointers to member functions.
>
> C++ supports pointers to member functions, yet using callback interfaces
> is a rather common idiom.
How do you declare a pointer to a member function, then? I thought you
had to keep a pointer to the object and then somehow invoke the proper
member function, but I don't know the syntax for that latter part?
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> (E.g., apparently you can overload the "->" operator... GAH! >_< OK, I
> am *so* not trying that out!)
You can overload the comma operator!
boost::assign does some nasty stuff with it, to let you add stuff to STL
containers like this:
std::vector<int> mylist;
mylist += 1,2,3,4; // uses overloaded += and , operators
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
