Hi,
I've read (in "joel on software") that, to avoid confusion between == and =,
when you sometimes use languages that use = as assignments AND comparisons,
you can do some comparisons like this :

  0 == myvalue

instead of

  myvalue == 0

the former causes an error if you put = instead of ==, which avoids potential
headaches later.

While it could seem very ordinary to hardcore programmers here, to me it's
very smart, and I would like to know if there's some place where I could
learn other little tricks like this...

any links ?

Fabien.

Post a reply to this message

Fa3ien <fab### [at] yourshoesskynetbe> wrote:
>   0 == myvalue

> instead of

>   myvalue == 0

  I have always disliked that "trick" because it breaks the logical way
to "read" the line. Nobody says "if zero is equal to this value". The
common expression is "if this value is equal to zero".

  I have seen some people go further and extend that "trick" to things
like:

    0 < money

  This always confuses me. Again, nobody says "if zero is smaller than
the amount of money". That sentence would be quite confusing. Naturally
everyone says "if the amount of money is larger than zero".

-- 
                                                          - Warp

Post a reply to this message

"Fa3ien" <fab### [at] yourshoesskynetbe> wrote

> I've read (in "joel on software") that, to avoid confusion between == and
=,
> when you sometimes use languages that use = as assignments AND
comparisons,
> you can do some comparisons like this :
>
>   0 == myvalue

I think the best "trick" is to use a programming language which was designed
with at least some forethought, so that such tricks are unnecessary.

Post a reply to this message

somebody <x### [at] ycom> wrote:
> I think the best "trick" is to use a programming language which was designed
> with at least some forethought, so that such tricks are unnecessary.

  Such languages may lack necessary libraries, support or efficiency.

-- 
                                                          - Warp

Post a reply to this message

>> I think the best "trick" is to use a programming language which was designed
>> with at least some forethought, so that such tricks are unnecessary.
> 
>   Such languages may lack necessary libraries, support or efficiency.

And that's the sad part. C is a horrid, horrid language, but it's where 
all the libraries are. All the "good" languages I've seen have a 
crippling lack of half-decent libraries... [And usually, rather limited 
documentation and unpolished toolchains.]

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   Such languages may lack necessary libraries, support or efficiency.

  Btw, often people wonder why C++ is so popular, given that there are
so many "better" languages out there.

  IMO one very important factor for the popularity of C++ is the staggering
amount of libraries for it. Since almost all C libraries can be used in C++,
the amount of available libraries is simply enormous.

  This is, IMO, often one of the major killers for new languages: Lack of
libraries. The language may be the most perfect language in the world, but
if you don't have libraries to do what you want, it's almost useless.
Nobody wants to reinvent the wheel for every little thing that has been
already implemented to death by other people.

-- 
                                                          - Warp

Post a reply to this message

Warp a écrit :
>   I have always disliked that "trick" because it breaks the logical way
> to "read" the line. Nobody says "if zero is equal to this value". The
> common expression is "if this value is equal to zero".

I mostly agree.  When I seen that trick, I also thought that it was not
very "natural", being the reverse of "this equals that".

However, there are many areas were programming require some kind
of backwards-thinking or even worse, so that's quite benign.

All in all, I don't recommend the trick or even think I'm gonna
use it myself, it was mostly an example of a small trick that
implies a little thinking, and I was wondering if there were any
other small programming tricks of that kind.

Fabien.

Post a reply to this message

somebody wrote:
> I think the best "trick" is to use a programming language which was designed
> with at least some forethought, so that such tricks are unnecessary.

Heh.

To answer the original question, check out the book "programming pearls".

I do the (0 == X) and it seems quite natural after a time. (And I 
occasionally get asked why I do such things in languages where 
assignment and equality don't get mixed up, like Tcl. :-)

I also do the "never use the > sign" in comparisons. It's not a question 
of how you read it out loud, but a question of putting the things in the 
right order. For example:

   0 < A & A < B
If A is between zero and B.

   A < B | C < A
If A is outside the range B to C.

   if (start + 300 < now)
If now is at least 300 seconds past when we started.

Start putting in complicated timestamp calculations, and it becomes very 
helpful. Always use < or <=, always add rather than subtract offsets, 
and I almost never make a mistake and get the wrong things being compared.

It's kind of like drawing a picture, rather than writing a sentence. 
IME, most programmers are more visual than auditory.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Invisible wrote:
> And that's the sad part. C is a horrid, horrid language, but it's where 
> all the libraries are. All the "good" languages I've seen have a 
> crippling lack of half-decent libraries...

That's why I'm looking at Erlang. Decent language, good efficiency, 
industrial-strength libraries.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Darren New wrote:
> Invisible wrote:
>> And that's the sad part. C is a horrid, horrid language, but it's 
>> where all the libraries are. All the "good" languages I've seen have a 
>> crippling lack of half-decent libraries...
> 
> That's why I'm looking at Erlang. Decent language, good efficiency, 
> industrial-strength libraries.

I did look at Erlang. (Let's face it, other than Lisp, it's the only 
remotely "popular" functional language. And Erikson is behind it, so 
that's a pretty damn big vote of confidence in the soundness of the 
technology.)

But alas, it's not purely functional, and the general style just seemed 
untidy and complicated. It's just not my cup of tea...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Warp wrote:

> 
>     0 < money
> 

Where that really comes into play is range statements:

if(10 < money && money < 100)
{
  ...
}

which can be read as "if money is between 10 and 100"

Someone I used to work with insisted that you use the same direction in 
comparisons if you had more than 1 comparison. It seemed to make sense 
when he used this example. The equivalent (and probably the way most 
people are familiar with handling ranges) "money > 10 && money < 100" 
isn't as quick to parse what you're looking for. Using that sort of 
statement with a single comparison seems a bit ridiculous to me, though.

I have seen and used the [Constant|Literal] == [Variable] syntax before, 
it's good for preventing assignment where you meant equality bugs. Of 
course, the problem becomes obvious when you begin debugging seemingly 
bizarre behavior. But, the objective is to prevent such behavior in the 
first place.

My favorite syntactical bug was the following:

for(int i = 0; i < cItems; i++);
{
    ... Block of code ...
}

It's subtle, and if your for loops are any more complex than the above 
trivial example, results in headaches. I spent an hour tracking 
something similar down in my early days.

Post a reply to this message

Invisible wrote:

> And that's the sad part. C is a horrid, horrid language, but it's where 
> all the libraries are. All the "good" languages I've seen have a 
> crippling lack of half-decent libraries... [And usually, rather limited 
> documentation and unpolished toolchains.]

Nothing wrong with C or it's derivatives. Once you've acquainted 
yourself with the syntax, it's quite powerful.

Then you can do such convenient things as:

int * DoStuff(int i)
{
   //... code for DoStuff here ...
}

int *(*pfunc)(int);

int main(int argc, char **argv)
{
    pfunc = DoStuff;

    // This will call DoStuff (In C# pfunc would be called a "delegate")
    int *pWhatever = pfunc(4096);
}

Post a reply to this message

Warp wrote:

>   IMO one very important factor for the popularity of C++ is the staggering
> amount of libraries for it. Since almost all C libraries can be used in C++,
> the amount of available libraries is simply enormous.

I'd venture to say C# also has an astounding amount of libraries (at 
least, on the Windows platform ...) the base library for .NET is pretty 
extensive, though not without limitations, but those can easily be 
worked around. I don't know whether the base libraries for Mono are as 
plentiful, as I only have very limited experience with Mono.

The drawback? It's not viewed as a high performance language.

Post a reply to this message

Warp wrote:
>   Btw, often people wonder why C++ is so popular, given that there are
> so many "better" languages out there.

What's wrong with C++? I just found out how to make a dynamic 2d array 
and save numbers to a file via binary representation. The possibilities 
just opened up...

>   IMO one very important factor for the popularity of C++ is the staggering
> amount of libraries for it. Since almost all C libraries can be used in C++,
> the amount of available libraries is simply enormous.

A very big plus :)

>   This is, IMO, often one of the major killers for new languages: Lack of
> libraries. The language may be the most perfect language in the world, but
> if you don't have libraries to do what you want, it's almost useless.
> Nobody wants to reinvent the wheel for every little thing that has been
> already implemented to death by other people.

This is why I'm giving up Euphoria. It was great when I has DOS, but now 
that I have XP, the best graphics library I could find was a sucky 
Allegro implementation. Very buggy and wasteful, since the best it can 
do is a difficult version of triple buffering, and only in certain video 
modes. I used to arrive at a better result using only *one* virtual 
screen...

C++ is great. If I don't like a certain library, I can find a new one. 
My current favorites are SDL (for CA sims) and HGE (for games). Irrlicht 
looks promising, though I haven't played with it much.

Sam

Post a reply to this message

Mike Raiford <mra### [at] hotmailcom> wrote:
> Where that really comes into play is range statements:

> if(10 < money && money < 100)
> {
>   ...
> }

> which can be read as "if money is between 10 and 100"

> Someone I used to work with insisted that you use the same direction in 
> comparisons if you had more than 1 comparison. It seemed to make sense 
> when he used this example. The equivalent (and probably the way most 
> people are familiar with handling ranges) "money > 10 && money < 100" 
> isn't as quick to parse what you're looking for. Using that sort of 
> statement with a single comparison seems a bit ridiculous to me, though.

  I don't have any problem in quickly understanding "money > 10 && money < 100"
because I use it so much.

  (OTOH, one could argue that understanding "0 < money" becomes easy when
you use it a lot...)

  The form you suggest becomes a bit counter-productive when the expression
is not a pure "between x and y", like for example:

if(10 < money*money && money*12 < 100)

  Now it becomes much harder to understand quickly what's going on.

> I have seen and used the [Constant|Literal] == [Variable] syntax before, 
> it's good for preventing assignment where you meant equality bugs. Of 
> course, the problem becomes obvious when you begin debugging seemingly 
> bizarre behavior. But, the objective is to prevent such behavior in the 
> first place.

  In most cases the compiler will issue a warning anyways if you make
the mistake. Never been a problem to me.

> My favorite syntactical bug was the following:

> for(int i = 0; i < cItems; i++);
> {
>     ... Block of code ...
> }

> It's subtle, and if your for loops are any more complex than the above 
> trivial example, results in headaches. I spent an hour tracking 
> something similar down in my early days.

  If the loop of the body uses 'i' (as is rather usual) you'll get a
compiler error.

-- 
                                                          - Warp

Post a reply to this message

Mike Raiford <mra### [at] hotmailcom> wrote:
> I'd venture to say C# also has an astounding amount of libraries (at 
> least, on the Windows platform ...) the base library for .NET is pretty 
> extensive, though not without limitations, but those can easily be 
> worked around. I don't know whether the base libraries for Mono are as 
> plentiful, as I only have very limited experience with Mono.

> The drawback? It's not viewed as a high performance language.

  And rather Windows-only.

-- 
                                                          - Warp

Post a reply to this message

stbenge <stb### [at] hotmailcom> wrote:
> What's wrong with C++?

  Some people don't like the fact that memory management requires great care.

-- 
                                                          - Warp

Post a reply to this message

Invisible wrote:
> But alas, it's not purely functional,

Yeah. I don't think you could get a real distributed language with 
everything being truly functional, could you? Certainly you couldn't do 
things like talking to device drivers in a *purely* functional way, 
methinks.  I mean, what's the functional equivalent of "the machine 
running the calculation just burst into flames"? :-)  What's the 
functional equivalent of "we've just released a new version of this 
function"?

> and the general style just seemed 
> untidy and complicated. It's just not my cup of tea...

Yep. Altho the language itself seems pretty simple and straightforward, 
the infrastructure used to support installs and reliability and such is 
pretty dense. Lots of forward references to stuff I haven't read yet, 
and I haven't yet found the roadmap to the right order to read things 
in. :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Mike Raiford wrote:
> Nothing wrong with C or it's derivatives.

There's lots wrong with it, and it isn't particularly powerful. On the 
other hand, it's straightforward and doesn't take a whole lot of runtime 
support, and it's simple enough that pretty much everyone does it the 
same way. (Unlike all the flavors of LISP, for example.)

(As for what's wrong with it, I simply cite autoconf and buffer overruns.)

>    // This will call DoStuff (In C# pfunc would be called a "delegate")

No it wouldn't.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

>> But alas, it's not purely functional,
> 
> Yeah. I don't think you could get a real distributed language with 
> everything being truly functional, could you?

Um... why?

> I mean, what's the functional equivalent of "the machine 
> running the calculation just burst into flames"? :-)

Throwing an exception, as a guess. Like a division by zero error, but 
less deterministic. (??!?!) ;-)

> What's the 
> functional equivalent of "we've just released a new version of this 
> function"?

Now that's an interesting question...

>> and the general style just seemed untidy and complicated. It's just 
>> not my cup of tea...
> 
> Yep. Altho the language itself seems pretty simple and straightforward, 

If by "simple and straight forward" you mean "assumes referential 
transparency but doesn't actually enforce it or make any attempt to 
check that it's there", then sure. Go knock yourself out. ;-)

> the infrastructure used to support installs and reliability and such is 
> pretty dense. Lots of forward references to stuff I haven't read yet, 
> and I haven't yet found the roadmap to the right order to read things 
> in. :-)

Gotta love documentation where you can't figure out what order to read 
it in...

OTOH, try just *finding* a good reference for Haskell for beginners...!

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Warp wrote:
> Mike Raiford <mra### [at] hotmailcom> wrote:
>> I'd venture to say C# also has an astounding amount of libraries (at 
>> least, on the Windows platform ...) the base library for .NET is pretty 
>> extensive, though not without limitations, but those can easily be 
>> worked around. I don't know whether the base libraries for Mono are as 
>> plentiful, as I only have very limited experience with Mono.
> 
>> The drawback? It's not viewed as a high performance language.
> 
>   And rather Windows-only.

Isn't that the whole point of the Mono project?

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Warp wrote:
> stbenge <stb### [at] hotmailcom> wrote:
>> What's wrong with C++?
> 
>   Some people don't like the fact that memory management requires great care.

I don't find it too difficult to delete every "new". Of course, I 
haven't coded anything too huge... yet.

Sam

Post a reply to this message

stbenge <stb### [at] hotmailcom> wrote:
> I don't find it too difficult to delete every "new".

  You would be surprised.

  There's a potential memory leak here:

void foo()
{
    char* s = new char[100];
    bar();
    delete[] s;
}

  There's a potential memory leak here:

class A
{
    char* s;

 public:
    A(): s(new char[100]) {}
    ~A() { delete[] s; }
};

  Naturally both of these leaks can be fixed by using cleaner code:

void foo()
{
    std::string s(100, ' ');
    bar();
}

class A
{
    std::string s;

 public:
    A(): s(100, ' ') {}
};

  No 'new' -> no leaks.

-- 
                                                          - Warp

Post a reply to this message

Warp a écrit :
> stbenge <stb### [at] hotmailcom> wrote:
>> I don't find it too difficult to delete every "new".
> 
>   You would be surprised.
>   No 'new' -> no leaks.
> 
Hey, but there are 'new's in the standard lib :-)

I think it would be more informative to give fixes that do not rely on 
the standard library... After all the 'new' operator exists for a 
reason, you don't always want to use the standard lib, and knowing what 
to do in these cases is useful.

No I won't do it as I'm not even sure I know where the leak is in the 
first case :-)

-- 
Vincent

Post a reply to this message

Warp escribió:
> stbenge <stb### [at] hotmailcom> wrote:
>> I don't find it too difficult to delete every "new".
> 
>   You would be surprised.
> 
>   There's a potential memory leak here:
> 
> void foo()
> {
>     char* s = new char[100];
>     bar();
>     delete[] s;
> }

If bar throws an exception, s won't be deleted. It can be avoided by 
using a smart pointer.

>   There's a potential memory leak here:
> 
> class A
> {
>     char* s;
> 
>  public:
>     A(): s(new char[100]) {}
>     ~A() { delete[] s; }
> };

Erm... No idea :) I know it could cause a double-free if you copy the 
object, since it doesn't have an explicit copy constructor and the 
default one doesn't do what we want in this case; but I don't know what 
could cause a leak.

>   Naturally both of these leaks can be fixed by using cleaner code:
> 
> void foo()
> {
>     std::string s(100, ' ');
>     bar();
> }
> 
> class A
> {
>     std::string s;
> 
>  public:
>     A(): s(100, ' ') {}
> };

Of course a string is better for this particular case :) Also avoids 
many possible buffer overflows (thought not all; operator[] is unchecked).

Post a reply to this message

Vincent Le Chevalier <gal### [at] libertyallsurfspamfr> wrote:
> I think it would be more informative to give fixes that do not rely on 
> the standard library... After all the 'new' operator exists for a 
> reason, you don't always want to use the standard lib, and knowing what 
> to do in these cases is useful.

  If the standard library cannot be used, then it becomes a bit complicated.

> No I won't do it as I'm not even sure I know where the leak is in the 
> first case :-)

  If bar() throws an exception you have a memory leak.

-- 
                                                          - Warp

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> Erm... No idea :) I know it could cause a double-free if you copy the 
> object, since it doesn't have an explicit copy constructor and the 
> default one doesn't do what we want in this case; but I don't know what 
> could cause a leak.

  Ok, not a leak per se, but accessing freed memory. (Although that would
require more member functions than I added there...)

-- 
                                                          - Warp

Post a reply to this message

Warp escribió:
> Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
>> Erm... No idea :) I know it could cause a double-free if you copy the 
>> object, since it doesn't have an explicit copy constructor and the 
>> default one doesn't do what we want in this case; but I don't know what 
>> could cause a leak.
> 
>   Ok, not a leak per se, but accessing freed memory. (Although that would
> require more member functions than I added there...)
> 

Ahh, then I can say I did figure out both.

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> Ahh, then I can say I did figure out both.

  Ok, if you want a harder puzzle, here's a curious quirk about C++ (not
related to memory leaks, though):

//------------------------------------------------------------------------
#include <map>

struct A { int i; };

struct Comp
{ bool operator()(const A& a1, const A& a2) const { return a1.i < a2.i; }
};

int main()
{
    std::map<A, int, Comp> theMap(Comp());
    A a = { 1 };
    theMap[a] = 5;
}
//------------------------------------------------------------------------

a) This doesn't compile. Without using a compiler, can you tell where
   is the problem and what is the exact reason why it doesn't compile?

b) If you can't see it, try it with a compiler. I bet you still can't see
   the problem... :P

c) In the erroneous line, can you tell me exactly what that line means?

d) What is the easiest way (smallest amount of extra code) to make it
   compile and work as expected?

-- 
                                                          - Warp

Post a reply to this message

Warp a écrit :
>   Ok, if you want a harder puzzle, here's a curious quirk about C++ (not
> related to memory leaks, though):
> 
> a) This doesn't compile. Without using a compiler, can you tell where
>    is the problem and what is the exact reason why it doesn't compile?
> 
> b) If you can't see it, try it with a compiler. I bet you still can't see
>    the problem... :P
> 
> c) In the erroneous line, can you tell me exactly what that line means?
> 
> d) What is the easiest way (smallest amount of extra code) to make it
>    compile and work as expected?
> 

Well I have no real idea of what goes wrong but I have a proposition for 
d) :-) Down below...

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

Replacing
     std::map<A, int, Comp> theMap(Comp());
with
     Comp c; std::map<A, int, Comp> theMap(c);
seems to do the trick as far as I figure. I don't like those anonymous 
objects anyhow ;-)

A trouble with references or some such ? That prevents the full 
instanciation of the map template ?

-- 
Vincent

Post a reply to this message

Warp escribió:
> Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
>> Ahh, then I can say I did figure out both.
> 
>   Ok, if you want a harder puzzle, here's a curious quirk about C++ (not
> related to memory leaks, though):
> 
> //------------------------------------------------------------------------
> #include <map>
> 
> struct A { int i; };
> 
> struct Comp
> { bool operator()(const A& a1, const A& a2) const { return a1.i < a2.i; }
> };
> 
> int main()
> {
>     std::map<A, int, Comp> theMap(Comp());
>     A a = { 1 };
>     theMap[a] = 5;
> }

Hrm, I never used map myself. I think I'll go search documentation on 
what the template parameters are.

> a) This doesn't compile. Without using a compiler, can you tell where
>    is the problem and what is the exact reason why it doesn't compile?
 >
> b) If you can't see it, try it with a compiler. I bet you still can't see
>    the problem... :P
> 
> c) In the erroneous line, can you tell me exactly what that line means?
> 
> d) What is the easiest way (smallest amount of extra code) to make it
>    compile and work as expected?

Oh I think I know. I took a while without noticing anything wrong, but 
now I remember having read about it in C++ FAQ Lite. theMap(Comp()) 
*declares a function* instead of instantiating an object. Good to know 
all the time I wast^H^H^H^H spent reading that website was actually useful.

Okay, *after* remembering that and writing that paragraph, I went and 
searched for what I remembered having read. Maybe that counts as 
cheating... I wouldn't have searched if I had read question D before, so 
I could try figuring out the solution myself :)

http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.2

The solution is:
std::map<A, int, Comp> theMap = Comp();

Post a reply to this message

Say I wrote

int** foo = NULL;
int nx = 22, ny = 17;

void matrixfunc(){
  foo = new int*[nx];

  for (int x = 0; x < nx; x++)
   foo[x] = new int[ny];
}


and called matrixfunc();, but before I could delete it

for (int x = 0; x < nx; x++)
  delete[] foo[x];

  delete[] foo;
  foo = NULL;

the code crashed. Do I have a memory leak?

Sam

Post a reply to this message

On Thu, 20 Mar 2008 00:52:55 +0100, stbenge <stb### [at] hotmailcom> wrote:

> Say I wrote
>
> int** foo = NULL;
> int nx = 22, ny = 17;
>
> void matrixfunc(){
>   foo = new int*[nx];
>
>   for (int x = 0; x < nx; x++)
>    foo[x] = new int[ny];
> }

Much better to use std::vector instead. Avoid raw pointers like the  

plague; it will save you many headaches.



> and called matrixfunc();, but before I could delete it
>
> for (int x = 0; x < nx; x++)
>   delete[] foo[x];
>
>   delete[] foo;
>   foo = NULL;
>
> the code crashed. Do I have a memory leak?

If by "crash" you mean unexpected program termination, then not really  

(not because of the crash anyway). Any modern desktop OS will reclaim th
e  

resources held by a program when said program terminates.



-- 

FE

Post a reply to this message

Warp wrote:
>   (OTOH, one could argue that understanding "0 < money" becomes easy when
> you use it a lot...)

Yes, it takes practice.

>   The form you suggest becomes a bit counter-productive when the expression
> is not a pure "between x and y", like for example:
> 
> if(10 < money*money && money*12 < 100)
> 
>   Now it becomes much harder to understand quickly what's going on.

If money squared is more than ten or money times twelve is less than a 
hundred.  Makes sense to me. :-)  But then, I'm used to it.

I've noticed since this came up that I'll even do things like
   if (i > 0^H^H^H^H^H0 < i) ....

>   In most cases the compiler will issue a warning anyways if you make
> the mistake. Never been a problem to me.

It depends on the language, and the compiler.  A lot of embedded 
compilers aren't too smart, and a lot of languages that adopted C syntax 
(PHP, Java, etc) aren't too smart about that too.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Invisible wrote:
>>> But alas, it's not purely functional,
>>
>> Yeah. I don't think you could get a real distributed language with 
>> everything being truly functional, could you?
> 
> Um... why?

Because it's nondeterministic? It's I/O driven? It's asynchronous?

I mean, to the extent that you think a tail-recursive function accepting 
asynchronous messages and sending asynchronous messages in return can be 
"functional," then it looks like Erlang is functional.

>> I mean, what's the functional equivalent of "the machine running the 
>> calculation just burst into flames"? :-)
> 
> Throwing an exception, as a guess. Like a division by zero error, but 
> less deterministic. (??!?!) ;-)

Who throws the exception? The machine running the calculation isn't in 
any shape to do so.

>> What's the functional equivalent of "we've just released a new version 
>> of this function"?
> 
> Now that's an interesting question...

Let me know when you figure it out. ;-)

>>> and the general style just seemed untidy and complicated. It's just 
>>> not my cup of tea...
>>
>> Yep. Altho the language itself seems pretty simple and straightforward, 
> 
> If by "simple and straight forward" you mean "assumes referential 
> transparency but doesn't actually enforce it or make any attempt to 
> check that it's there", then sure. Go knock yourself out. ;-)

Where do you think it doesn't assume referential transparency?

By "simple and straightforward" I meant in the sense that there are 
relatively few types and primitives and interactions between them. More 
like Tcl or C than Ada or C++.

> Gotta love documentation where you can't figure out what order to read 
> it in...

It's not unusual. It's how I learned most of the languages I know. But 
then, most of the languages I learned that way didn't have 1500+ pages 
of documentation for the libraries. :-)  A two-pass read of the library 
docs is going to take a while.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Warp wrote:
> stbenge <stb### [at] hotmailcom> wrote:
>> What's wrong with C++?
> 
>   Some people don't like the fact that memory management requires great care.

My understanding is that there are piles and piles of gotchas you have 
to learn about before you can make reliable programs, even if you stay 
within the definition of the language and don't start doing threads or 
dynamic code loading or things like that.

With C, for example, there are only a handful of gotchas you have to 
learn about. Stuff like "don't run off allocated memory", "don't fail to 
declare types of function arguments and returns", "make sure your 
definitions match your declarations", "put parens around your macros", etc.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Vincent Le Chevalier <gal### [at] libertyallsurfspamfr> wrote:
> Replacing
>      std::map<A, int, Comp> theMap(Comp());
> with
>      Comp c; std::map<A, int, Comp> theMap(c);

  That's not the shortest possible solution.

> A trouble with references or some such ? That prevents the full 
> instanciation of the map template ?

  No.

-- 
                                                          - Warp

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> Oh I think I know. I took a while without noticing anything wrong, but 
> now I remember having read about it in C++ FAQ Lite. theMap(Comp()) 
> *declares a function* instead of instantiating an object.

  But why? Doesn't "Comp()" create an object? How can you declare a function
with an object (instead of a type)?

  What kind of function? What does it return? Does it take parameters?
What is the type of those parameters?

> The solution is:
> std::map<A, int, Comp> theMap = Comp();

  Alternatively you can do:

std::map<A, int, Comp> theMap((Comp()));

(which would be necessary if the map constructor took more than one such
parameter...)

-- 
                                                          - Warp

Post a reply to this message

Fredrik Eriksson <fe79}--at--{yahoo}--dot--{com> wrote:
> On Thu, 20 Mar 2008 00:52:55 +0100, stbenge <stb### [at] hotmailcom> wrote:
> > Say I wrote
> >
> > int** foo = NULL;
> > int nx = 22, ny = 17;
> >
> > void matrixfunc(){
> >   foo = new int*[nx];
> >
> >   for (int x = 0; x < nx; x++)
> >    foo[x] = new int[ny];
> > }

> Much better to use std::vector instead. Avoid raw pointers like the  
> plague; it will save you many headaches.

  Yeah. You can do that with a one-liner:

std::vector<std::vector<int> > foo(nx, std::vector<int>(ny));

  And you don't have to delete anything.

-- 
                                                          - Warp

Post a reply to this message

Darren New wrote:
> Invisible wrote:
>>>> But alas, it's not purely functional,
>>>
>>> Yeah. I don't think you could get a real distributed language with 
>>> everything being truly functional, could you?
>>
>> Um... why?
> 
> Because it's nondeterministic? It's I/O driven? It's asynchronous?
> 
> I mean, to the extent that you think a tail-recursive function accepting 
> asynchronous messages and sending asynchronous messages in return can be 
> "functional," then it looks like Erlang is functional.

Haskell supports random number generators. And I/O. And asynchronous 
exceptions. It just cleanly seperates what *is* deterministic from what 
is *not*, that's all. ;-)

>>> I mean, what's the functional equivalent of "the machine running the 
>>> calculation just burst into flames"? :-)
>>
>> Throwing an exception, as a guess. Like a division by zero error, but 
>> less deterministic. (??!?!) ;-)
> 
> Who throws the exception? The machine running the calculation isn't in 
> any shape to do so.

I would presume the exception is just thrown to whoever is waiting for 
the answer?

>>> What's the functional equivalent of "we've just released a new 
>>> version of this function"?
>>
>> Now that's an interesting question...
> 
> Let me know when you figure it out. ;-)

To be honest, I'm not really seeing a clean way to handle this in *any* 
language, but I haven't thought about it for that long yet.

>> If by "simple and straight forward" you mean "assumes referential 
>> transparency but doesn't actually enforce it or make any attempt to 
>> check that it's there", then sure. Go knock yourself out. ;-)
> 
> Where do you think it doesn't assume referential transparency?

Please reparse my sentence. I said it *does* assume referential 
transparency yet does nothing to *enforce* or even *check* for it.

In other words, if you're not careful, you can easily cause the system 
to massively malfunction with a few incautiously chosen commands.

> By "simple and straightforward" I meant in the sense that there are 
> relatively few types and primitives and interactions between them. More 
> like Tcl or C than Ada or C++.

I consider Haskell to be quite simple in this respect too. Until you 
start digging things up out of the standard libraries, the language 
itself gives you lists, tuples, integers, reals, booleans, characters, 
and that's more or less it. And the language is nearly devoid of 
keywords. (Decide for yourself if that's good or bad.)

>> Gotta love documentation where you can't figure out what order to read 
>> it in...
> 
> It's not unusual. It's how I learned most of the languages I know. But 
> then, most of the languages I learned that way didn't have 1500+ pages 
> of documentation for the libraries. :-)  A two-pass read of the library 
> docs is going to take a while.

I'm looking at you, Oracle. Trying to figure out where to start reading 
to actually comprehend this stuff is *far* too hard!

It's not that Oracle is hard to understand - just that the [multiple] 
manuals explain it quite poorly.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Warp wrote:

> 
>   The form you suggest becomes a bit counter-productive when the expression
> is not a pure "between x and y", like for example:
> 
> if(10 < money*money && money*12 < 100)
> 
>   Now it becomes much harder to understand quickly what's going on.
> 

Right, and I don't think I'd dare use that form for a set of comparisons 
like that. But for simple ranges, it makes sense.

> 
>   In most cases the compiler will issue a warning anyways if you make
> the mistake. Never been a problem to me.
> 

Until you're working on some project where someone has set the Warning 
level so low that there are no warnings. (I have run into that, and 
setting the warning level any higher scared me ... so many warnings...)

>> My favorite syntactical bug was the following:
> 
>> for(int i = 0; i < cItems; i++);
>> {
>>     ... Block of code ...
>> }
> 
>> It's subtle, and if your for loops are any more complex than the above 
>> trivial example, results in headaches. I spent an hour tracking 
>> something similar down in my early days.
> 
>   If the loop of the body uses 'i' (as is rather usual) you'll get a
> compiler error.
> 

Without opening the argument on MS compiler vs a truly ANSI compliant 
compiler, that is not the case with Visual C++. It happily compiles the 
code because i is still declared after the for loop.

(I dislike this sort of behavior, and IIRC, they fixed it in more recent 
versions, but have an option to keep it compatible with code written in 
older versions)

Post a reply to this message

Invisible wrote:
> Warp wrote:
>> Mike Raiford <mra### [at] hotmailcom> wrote:
>>> I'd venture to say C# also has an astounding amount of libraries (at 
>>> least, on the Windows platform ...) the base library for .NET is 
>>> pretty extensive, though not without limitations, but those can 
>>> easily be worked around. I don't know whether the base libraries for 
>>> Mono are as plentiful, as I only have very limited experience with Mono.
>>
>>> The drawback? It's not viewed as a high performance language.
>>
>>   And rather Windows-only.
> 
> Isn't that the whole point of the Mono project?
> 

I thought so. But the caveat is this:

Programs written to the MS .NET Framework, will not run under the Mono 
.NET Framework, and vice-versa. Though you can write software in C# 
using Mono as the framework, and have it run under Windows, and various 
Linux flavors.

Post a reply to this message

Darren New wrote:

>>    // This will call DoStuff (In C# pfunc would be called a "delegate")
> 
> No it wouldn't.
> 

Aside from multicast delegates, Doesn't a delegate act similar to a 
function pointer?

Post a reply to this message

Warp wrote:
>   Yeah. You can do that with a one-liner:
> 
> std::vector<std::vector<int> > foo(nx, std::vector<int>(ny));
> 
>   And you don't have to delete anything.
> 

Hmm, I'll consider using this in the future. If I'm lucky, I can even 
change my existing code to accommodate it. Thanks!

Sam

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> > Oh I think I know. I took a while without noticing anything wrong, but 
> > now I remember having read about it in C++ FAQ Lite. theMap(Comp()) 
> > *declares a function* instead of instantiating an object.

>   But why? Doesn't "Comp()" create an object? How can you declare a function
> with an object (instead of a type)?

>   What kind of function? What does it return? Does it take parameters?
> What is the type of those parameters?

  Nobody probably cares, but the answer is:

std::map<A, int, Comp> theMap(Comp());

declares a function called 'theMap' which returns a value of type
std::map<A, int, Comp> and takes one parameter: A pointer to a function
which takes no parameters and which returns a value of type Comp.

  The reason *why* this is so is apparently because of backwards
compatibility with old C code, and something the C++ standardization
committee really didn't want to include in the standard, but they had
little alternatives (lest they break a lot of existing code).

-- 
                                                          - Warp

Post a reply to this message

Darren New wrote:
> Warp wrote:
>> if(10 < money*money && money*12 < 100)
>>
>>   Now it becomes much harder to understand quickly what's going on.
> 
> If money squared is more than ten or money times twelve is less than a 
> hundred.  Makes sense to me. :-)  But then, I'm used to it.

To be clear, I think it's harder to understand because it's nonsensical, 
not because the comparisons are in the wrong order. Is it any harder to 
understand that than

    if(money*money > 10 && money*12 < 100)

??  I'd say the failure here is naming the "money" variable incorrectly 
and not abstracting out the meaning.
   interest_basis = money * money;
   total_interest = money * 12;
   if (10 < interest_basis && total_interest < 100) ...


-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Invisible wrote:
> Haskell supports random number generators. And I/O. And asynchronous 
> exceptions. It just cleanly seperates what *is* deterministic from what 
> is *not*, that's all. ;-)

So does Erlang, from what I can see. Every statement always works the 
same way. It's nondeterministic because it depends on the timing of 
statements between asynchronous events. But once a message is in your 
queue, you'll process it the same way every time. Again, as far as I can 
tell from my reading so far...

Now, Erlang does have stuff like the "process dictionary" that is 
imperative, but every mention of it is followed by "don't use this if 
you don't know what you're doing, because it's stateful and imperative!"

>> Who throws the exception? The machine running the calculation isn't in 
>> any shape to do so.
> 
> I would presume the exception is just thrown to whoever is waiting for 
> the answer?

Right. As an asynchronous message, unless you're not trapping it, in 
which case you too throw the same message.

(You don't wait for results. You send a message, and optionally wait for 
one to come back, perhaps with a timeout. But you can "link" processes, 
which means a failure of one of them will cause the others to fail with 
the same exit code, unless they're "trapping exits", in which case the 
failure will be translated into a notification.)

So, overall, still functional.

> To be honest, I'm not really seeing a clean way to handle this in *any* 
> language, but I haven't thought about it for that long yet.

Erlang does it by running the old version and new version at once. As 
long as your code only makes local calls, it keeps running the old code. 
If it makes a tail-recursive call to a fully-qualified method, then the 
latest version of that method gets run.

So you have code like this (not in actual erlang syntax):
   method myserver::loop(State)
     receive {request, Params} from Sender ->
        {Result, NewState} = calculate(Params, State);
        send Result to Sender;
        loop(NewState);
     receive {upgrade, TransformFunction} ->
        NewState = TransformFunction(State);
        myserver::loop(NewState);
   end.

So it runs along happily, processing requests, in the loop. If you want 
to upgrade, you recompile the code, load the new version, write an 
anonymous function that transforms the data the server is holding from 
what the old version uses to what the new version uses, and tell the 
server to restart the loop after passing the state through the transform.

And this is all managed by the release management code, too. *That* is 
the complicated part: all the infrastructure already built.

>>> If by "simple and straight forward" you mean "assumes referential 
>>> transparency but doesn't actually enforce it or make any attempt to 
>>> check that it's there", then sure. Go knock yourself out. ;-)
>>
>> Where do you think it doesn't assume referential transparency?
> 
> Please reparse my sentence. I said it *does* assume referential 
> transparency yet does nothing to *enforce* or even *check* for it.

> In other words, if you're not careful, you can easily cause the system 
> to massively malfunction with a few incautiously chosen commands.

Like what?  I mean, that's true in some sense, but it's true of any 
system depending on what you mean by "massively malfunction". Since 
processes *can* have side-effects, you don't get referential 
transparency. But I don't think you have that with monads in Haskell, 
either, yes?  Are references to the IO monad referentially transparent? 
I thought that was kind of the point of monads.

>> By "simple and straightforward" I meant in the sense that there are 
>> relatively few types and primitives and interactions between them. 
>> More like Tcl or C than Ada or C++.
> 
> I consider Haskell to be quite simple in this respect too. 

Yes, exactly.

> I'm looking at you, Oracle. Trying to figure out where to start reading 
> to actually comprehend this stuff is *far* too hard!

Just Oracle, or SQL in general?  But yah, giant lumps of code like that 
are a mess to grok.

I once was looking at a program called Scopus (functionality not unlike 
SAP), and I spent literally a full work day trying to get a record 
entered into the database.

Me: Create a contact.
It: You first have to create the company the contact works for.
Me: Create a company.
It: You have to create the city the company is in.
Me: Create a city.
It: You first have to create the salesman responsible for that city.
Me: Create a salesman
It: You first have to create the department the salesman works for.

Literally. I gave up after about 40 of these indirections, some of which 
seemed circular.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Mike Raiford wrote:
> Darren New wrote:
> 
>>>    // This will call DoStuff (In C# pfunc would be called a "delegate")
>>
>> No it wouldn't.
>>
> 
> Aside from multicast delegates, Doesn't a delegate act similar to a 
> function pointer?

Only if you disregard that they're multicast and object-oriented and can 
be targets of events.  I'll grant you that "delegate" is as close as C# 
has to the concept of "pointer to function". :)

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Mike Raiford wrote:
> Programs written to the MS .NET Framework, will not run under the Mono 
> ..NET Framework, and vice-versa. 

It depends on the program.  ASP.NET stuff runs quite smoothly.  Stuff 
you write that depends on libraries that haven't been ported yet 
doesn't, no. :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Invisible wrote:
>> Where do you think it doesn't assume referential transparency?
> 
> Please reparse my sentence. I said it *does* assume referential 
> transparency yet does nothing to *enforce* or even *check* for it.

What does Haskell do to enforce referential transparency, by the way? I 
don't really understand monads any more, but it would seem to me that if 
you piped the standard output of a Haskell program into a second Haskell 
program, then the output of the second one back into the first one, you 
could see some odd "non-transparent" things happen as each program's 
output affected its input, yes?

Otherwise, I'm not sure where Erlang falls down, other than, as I said, 
the obvious places where you're actually actively writing things to 
disks and reading them back later.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message