![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> Orchid XP v8 <voi### [at] dev null> wrote:
>> Question: What happens if your class doesn't have the comparison operator?
>
> If there's no way you can add an operator<() for your class, then you
> can give std::set a comparator.
> It is also possible to create a comparison function and use as a functor
> (as you might remember). However, the syntax of the TheSetType definition
> becomes a bit complicated.
>
> By the way, std::set (as well as std::map) *always* takes a comparator
> (rather than using the < operator directly). When none is specified, the
> default comparator used is std::less which, by template magic, makes it
> completely equivalent to comparing the elements with the < operator
> directly.
>
> This is good to know because you might sometimes want the elements
> sorted in some other way.
Sounds quite flexible.
(In particular, Haskell's own Data.Set provides no way to specify an
alternate comparison operator. But then again, it only needs *a*
comparison operator; which one you use doesn't really affect anything
user-visible. The "sort" function allows you to specify a comparison
operator manually though...)
What I was really interested to know is whether trying to construct a
set without a comparison operator yields a compile-time error, a runtime
error, or simply undefined behaviour.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Orchid XP v8 <voi### [at] dev null> wrote:
> What I was really interested to know is whether trying to construct a
> set without a comparison operator yields a compile-time error, a runtime
> error, or simply undefined behaviour.
We are talking about templates here. Everything happens at compile
time. :)
(Although the error message will probably be quite obfuscated. With
the next C++ standard compilers will have means to directly say "your
type has no operator< but one is required".)
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Slime wrote:
> thing after another. It's a lot like math - they don't teach fractions to
> first graders because they need to spend time learning addition and
> subtraction to fully master the concepts.
Ummm... They do teach basic fractions to first graders nowadays.
--
~Mike
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Orchid XP v8 wrote:
> I was thinking maybe I'd try implementing a Huffman coder. I need a
> binary tree for that. Does STL happen to have one already? (That would
> obviously be the simplest thing...)
Oooh, one of my first toy projects :) IIRC once I learned the concept,
it was deceptively simple to write.
--
~Mike
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Mon, 29 Sep 2008 07:53:51 -0500, Mike Raiford <"m[raiford]!at"@gmail.com> wrote:
>Ummm... They do teach basic fractions to first graders nowadays.
... and now algebra in sixth grade.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> What I was really interested to know is whether trying to construct a
>> set without a comparison operator yields a compile-time error, a runtime
>> error, or simply undefined behaviour.
>
> We are talking about templates here. Everything happens at compile
> time. :)
In my book, finding out at compile time that you did something wrong
beats the **** out of finding that out at runtime. ;-)
Unfortunately, C tends to be a language that says "hey, you wanna do
something crazy? Who am I to stop you? You know what you're doing, right?"
It's nice to see that C++ moves away from that a little.
> (Although the error message will probably be quite obfuscated. With
> the next C++ standard compilers will have means to directly say "your
> type has no operator< but one is required".)
That's nice to have too...
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible wrote:
> It's nice to see that C++ moves away from that a little.
C++ is still a wonderful tool to shoot yourself in the foot.
I forget who said it, but I remember a quote:
"C allows you to shoot yourself in the foot. C++ allows you to shoot
yourself in the foot and reuse the bullet"
--
~Mike
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Mike Raiford wrote:
> I forget who said it, but I remember a quote:
>
> "C allows you to shoot yourself in the foot. C++ allows you to shoot
> yourself in the foot and reuse the bullet"
...and Haskell allows you to pretend to shoot yourself in the foot but
actually remain unharmed although nobody else really understands why? ;-)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Mike Raiford <"m[raiford]!at"@gmail.com> wrote:
> "C allows you to shoot yourself in the foot. C++ allows you to shoot
> yourself in the foot and reuse the bullet"
OTOH C++ allows much better than C to build automatic or semi-automatic
safeguards which will prevent or at least diminish the danger of shooting
yourself in the foot (at least as long as you use those safeguards properly).
Of course one limiting factor in making C++ more secure is its policy
that you don't have to pay for what you don't use, and that there should
be as little hidden overhead in correct code as possible (in other words,
adding automatic checks to *correct* code is basically a waste).
On the other hand, the C++ standard doesn't forbid compilers from adding
additional checks (eg. in debug mode) if they want. In fact, most of the
better compilers *do* add additional checks to things when they compile
in debug mode.
Very unfortunately gcc is *not* one of those compilers... :(
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Mike Raiford wrote:
> Orchid XP v8 wrote:
>
>> I was thinking maybe I'd try implementing a Huffman coder. I need a
>> binary tree for that. Does STL happen to have one already? (That would
>> obviously be the simplest thing...)
>
> Oooh, one of my first toy projects :) IIRC once I learned the concept,
> it was deceptively simple to write.
I usually do Jotto first. It's got more twisty ways you can take it.
http://darren.s3.amazonaws.com/functional.txt
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |