In article <OaSdnQ1OjuhcE4banZ2dnUVZ8qOtnZ2d@bt.com>,
Malcolm McLean <regniztar@btinternet.com> wrote:
>
>"Kenny McCormack" <gazelle@xmission.xmission.com> wrote in message
>>
>> But here's the thing: I seriously doubt that, in the hosted world (at
>> any rate), anything that can be written in "ISO C" (or whatever term you
>> prefer) should be. I.e., anything that is that pure (such as your fuzzy
>> logic program) could be written much more easily and readably in
>> something like AWK.
>>
>I don't know AWK. If you've got time, try doing it. Seriously. I am not in
>the business of selling C compilers, and if fuzzy logic trees are better
>implemented in another language I'd be glad to be aware of it.

I may just do that. No promises, but I might get around to it at some
point.

On Sun, 21 Oct 2007 18:39:13 +0100, in comp.lang.c , "Malcolm McLean"
<regniztar@btinternet.com> wrote:

>
>"Kenny McCormack" <gazelle@xmission.xmission.com> wrote in message
>>
>> But here's the thing: I seriously doubt that, in the hosted world (at
>> any rate), anything that can be written in "ISO C" (or whatever term you
>> prefer) should be.

Kenny's delusions are hard to understand.

> I.e., anything that is that pure (such as your fuzzy
>> logic program) could be written much more easily and readably in
>> something like AWK.
>>
>I don't know AWK. If you've got time, try doing it. Seriously.

I _do_ know awk, a little, and its not the beast for the job. awk with
sed, grep, cat and tr, possibly. Yikes.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

On Oct 22, 12:38 am, Mark McIntyre <markmcint...@spamcop.net> wrote:
> On Sun, 21 Oct 2007 18:39:13 +0100, in comp.lang.c , "Malcolm McLean"

> <regniz...@btinternet.com> wrote:

> >"Kenny McCormack" <gaze...@xmission.xmission.com> wrote in message

> >> But here's the thing: I seriously doubt that, in the hosted world (at
> >> any rate), anything that can be written in "ISO C" (or whatever term you
> >> prefer) should be.

> Kenny's delusions are hard to understand.

Yes. It depends on the application domain. In the domains I've
worked in, it's probably true: I need sockets, and generally
threads or a data base. But earlier in my career, I wrote
compilers, and there's nothing in them which can't be readily
expressed in ISO C; this is likely true for any other
application which simply reads input, does some calculations or
transformations, and writes it as output. I've got a lot of
little er programs which are written in pure ISO C++, and
could almost certainly be written in ISO C with a bit more
effort.

> > I.e., anything that is that pure (such as your fuzzy
> > logic program) could be written much more easily and readably in
> > something like AWK.

> >I don't know AWK. If you've got time, try doing it. Seriously.

> I _do_ know awk, a little, and its not the beast for the job.
> awk with sed, grep, cat and tr, possibly. Yikes.

It depends on what the job it, but I agree that I usually end up
using it within a shell script, if only to handle options.

Where AWK really breaks down is when the code gets large enough
that you want to maintain it in separate files. But I use it a
lot for smaller things.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Sat, 20 Oct 2007 20:45:58 -0000, gnuist006@gmail.com wrote:
> NOTE: I am really afraid of try-catch-throw. I have never been
> able to understand it since it does not exist in C and I cant
> really visualize the construct in terms of C.

How try-catch-throw is actually implemented depends on the compiler,
but one can explain it like this.

Assume the following C++ code is written:

#include <cstdio>

// here's a sample object with a constructor and destructor
// to demonstrate scope.
class someobj
{
public:
someobj() { std::puts("constructor"); }
~someobj() { std::puts("destructor"); }
private:
int x; // a dummy member variable
};

// A dummy type, it could be a typedef of int or whatever.
// Just for the purpose of throwing an exception of this particular type.
struct someexceptiontype
{
};

void code_that_may_throw()
{
someobj obj; // instantiating someobj in this scope.

if(false != true)
{
// some error situation happened, throw an exception.
// someexceptiontype() instantiates an object of
// "someexceptiontype" (without binding it into a variable),
// and throw throws it.
throw someexceptiontype();
}

std::puts("wow, false is true");
}

void some_intermediate_function()
{
std::puts("1");
code_that_may_throw();
std::puts("2");
}

int main()
{
try
{
some_intermediate_function();
std::puts("executed without hitch");
}
catch(int e)
{
std::puts("caught an int");
}
catch(someexceptiontype e)
{
std::puts("caught someexceptiontype");
}
std::puts("end of main()");
return 0;
}

The code above contains high-level concepts that approximately translate
to the following lower-level concepts in C. It could be implemented
differently, but the function is the same.

#include <stdio.h>

typedef struct someobj
{
int x;
} someobj;

void someobj__construct(someobj* this)
{
puts("constructor");
if(__system_exception_ptr) goto __scope_end;
__scope_end: ;
}
void someobj__destruct(someobj* this)
{
puts("destructor");
if(__system_exception_ptr) goto __scope_end;
__scope_end: ;
}

struct someexceptiontype
{
};

/*** This global code is defined in some system library by the compiler */
void* __system_exception_ptr = (void*)0;
int __system_exception_type = 0;
void __clear_exception()
{
__system_exception_type = 0;
free(__system_exception_ptr);
__system_exception_ptr = (void*)0;
}
/*** End of compiler library code */

void code_that_may_throw(void)
{
someobj obj; // instantiating someobj in this scope.
someobj__construct(&obj);
if(__system_exception_ptr) goto __scope_end_before_obj;

if(0 != 1)
{
someexceptiontype* e = (someexceptiontype*) malloc(sizeof(*e));
__system_exception_ptr = e;
__system_exception_type = 2;
/* ^ a compiler-specific tag that identifies the exception type */
goto __scope_end;
}

puts("wow, false is true");
if(__system_exception_ptr) goto __scope_end;

__scope_end: ;
someobj__destruct(&obj);
__scope_end_before_obj: ;
}

void some_intermediate_function(void)
{
puts("1");
if(__system_exception_ptr) goto __scope_end;

code_that_may_throw();
if(__system_exception_ptr) goto __scope_end;

puts("2");
if(__system_exception_ptr) goto __scope_end;
__scope_end: ;
}

int main(void)
{
some_intermediate_function();
if(__system_exception_ptr) goto try_catch;
puts("executed without hitch");
if(__system_exception_ptr) goto __scope_end;
goto past_catch;
try_catch: ;
switch(__system_exception_type)
{
case 1: /* example denoting int type */
{
__clear_exception();
puts("caught an int");
if(__system_exception_ptr) goto __scope_end;
break;
}
case 2: /* example denoting someexceptiontype */
{
__clear_exception();
puts("caught someexceptiontype");
if(__system_exception_ptr) goto __scope_end;
break;
}
default:
goto __scope_end; /* still not caught */
}
past_catch: ;
puts("end of main()");
if(__system_exception_ptr) goto __scope_end;

__scope_end: ;
return 0;
}

Of course, for efficiency reasons there is no "if" test after every
function return for exceptions (rather, execution may be transferred
to a dedicated stack and scope unfolder when an exception happens),
but this was the easiest way to explain what happens as regards for
scopes and execution paths.
Also, in the exception handler (catch {}), the exception object is
not supposed to be deallocated until the end of the handler, but
for simplicity I wrote the deallocation first.

Followups set to comp.lang.c++ .

--
Joel Yliluoma - http://bisqwit.iki.fi/
: comprehension = 1 / (2 ^ precision)

On Sat, 20 Oct 2007 20:45:58 -0000, gnuist006@gmail.com wrote:
> NOTE: I am really afraid of try-catch-throw. I have never been
> able to understand it since it does not exist in C and I cant
> really visualize the construct in terms of C.

How try-catch-throw is actually implemented depends on the compiler,
but one can explain it like this.

Assume the following C++ code is written:

#include <cstdio>

// here's a sample object with a constructor and destructor
// to demonstrate scope.
class someobj
{
public:
someobj() { std::puts("constructor"); }
~someobj() { std::puts("destructor"); }
private:
int x; // a dummy member variable
};

// A dummy type, it could be a typedef of int or whatever.
// Just for the purpose of throwing an exception of this particular type.
struct someexceptiontype
{
};

void code_that_may_throw()
{
someobj obj; // instantiating someobj in this scope.

if(false != true)
{
// some error situation happened, throw an exception.
// someexceptiontype() instantiates an object of
// "someexceptiontype" (without binding it into a variable),
// and throw throws it.
throw someexceptiontype();
}

std::puts("wow, false is true");
}

void some_intermediate_function()
{
std::puts("1");
code_that_may_throw();
std::puts("2");
}

int main()
{
try
{
some_intermediate_function();
std::puts("executed without hitch");
}
catch(int e)
{
std::puts("caught an int");
}
catch(someexceptiontype e)
{
std::puts("caught someexceptiontype");
}
std::puts("end of main()");
return 0;
}

The code above contains high-level concepts that approximately translate
to the following lower-level concepts in C. It could be implemented
differently, but the function is the same.

#include <stdio.h>

typedef struct someobj
{
int x;
} someobj;

void someobj__construct(someobj* this)
{
puts("constructor");
if(__system_exception_ptr) goto __scope_end;
__scope_end: ;
}
void someobj__destruct(someobj* this)
{
puts("destructor");
if(__system_exception_ptr) goto __scope_end;
__scope_end: ;
}

struct someexceptiontype
{
};

/*** This global code is defined in some system library by the compiler */
void* __system_exception_ptr = (void*)0;
int __system_exception_type = 0;
void __clear_exception()
{
__system_exception_type = 0;
free(__system_exception_ptr);
__system_exception_ptr = (void*)0;
}
/*** End of compiler library code */

void code_that_may_throw(void)
{
someobj obj; // instantiating someobj in this scope.
someobj__construct(&obj);
if(__system_exception_ptr) goto __scope_end_before_obj;

if(0 != 1)
{
someexceptiontype* e = (someexceptiontype*) malloc(sizeof(*e));
__system_exception_ptr = e;
__system_exception_type = 2;
/* ^ a compiler-specific tag that identifies the exception type */
goto __scope_end;
}

puts("wow, false is true");
if(__system_exception_ptr) goto __scope_end;

__scope_end: ;
someobj__destruct(&obj);
__scope_end_before_obj: ;
}

void some_intermediate_function(void)
{
puts("1");
if(__system_exception_ptr) goto __scope_end;

code_that_may_throw();
if(__system_exception_ptr) goto __scope_end;

puts("2");
if(__system_exception_ptr) goto __scope_end;
__scope_end: ;
}

int main(void)
{
some_intermediate_function();
if(__system_exception_ptr) goto try_catch;
puts("executed without hitch");
if(__system_exception_ptr) goto try_catch;
goto past_catch;
try_catch: ;
switch(__system_exception_type)
{
case 1: /* example denoting int type */
{
__clear_exception();
puts("caught an int");
if(__system_exception_ptr) goto __scope_end;
break;
}
case 2: /* example denoting someexceptiontype */
{
__clear_exception();
puts("caught someexceptiontype");
if(__system_exception_ptr) goto __scope_end;
break;
}
default:
goto __scope_end; /* still not caught */
}
past_catch: ;
puts("end of main()");
if(__system_exception_ptr) goto __scope_end;

__scope_end: ;
return 0;
}

Of course, for efficiency reasons there is no "if" test after every
function return for exceptions (rather, execution may be transferred
to a dedicated stack and scope unfolder when an exception happens),
but this was the easiest way to explain what happens as regards for
scopes and execution paths.
Also, in the exception handler (catch {}), the exception object is
not supposed to be deallocated until the end of the handler, but
for simplicity I wrote the deallocation first.

Followups set to comp.lang.c++ .

--
Joel Yliluoma - http://bisqwit.iki.fi/
: comprehension = 1 / (2 ^ precision)

> NOTE: I am really afraid of try-catch-throw. I have never been
> able to understand it since it does not exist in C and I can't
> really visualize the construct in terms of C. That is what my

Actually, these constructs pretty much exist in C as well: `catch' is called
`setjmp', and `throw' is called `longjmp'.


Stefan

On Oct 23, 9:33 am, Stefan Monnier <monn...@iro.umontreal.ca> wrote:
> > NOTE: I am really afraid of try-catch-throw. I have never been
> > able to understand it since it does not exist in C and I can't
> > really visualize the construct in terms of C. That is what my
>
> Actually, these constructs pretty much exist in C as well: `catch' is called
> `setjmp', and `throw' is called `longjmp'.
>
> Stefan

Is it in some obscure corner of K&R ANSI ? I was never taught this one
by my instructor. Can you explain its syntax and patterns of usage ?

Stefan Monnier wrote:
>> NOTE: I am really afraid of try-catch-throw. I have never been
>> able to understand it since it does not exist in C and I can't
>> really visualize the construct in terms of C. That is what my
>
> Actually, these constructs pretty much exist in C as well: `catch' is
> called `setjmp', and `throw' is called `longjmp'.

I believe a better way would be to imagine that 'try', not 'catch',
is called 'setjmp'.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask