possible useful macros...

[io_x]

what about these macro?

#define MM malloc
#define FF free
#define ooo cout

[Ben Pfaff]

They look obfuscatory.

[John Gordon]

How are these useful?

--
John Gordon A is for Amy, who fell down the stairs
gor...@panix.com B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

[David T. Ashley]

Macros and constants are overused. I've seen some awful things in my
career.

There is nothing wrong with magic numbers, and you can embed them
directly.

I've seen nonsense like this:

#define TWICE 2
for (i=0; i<TWICE; i++) //Read the pushbutton twice, to be sure.
...

The only valid reasons to define a simple preprocessor substitution
are:

a)When you change one instance, you have to change them all for the
program to be correct.

b)The constant has a high probability of changing, and you'd like to
bundle all such things together where they can be changed without
hunting through the program.

c)Symbolic clarity, i.e. "PI", "MAX_NUMBER_OF_TARGETS", etc.

The macros you've suggested are simple substitutions and are useless
and serve no purpose. "MM" is not clearer than "malloc". In fact, it
is less clear.

I frankly don't even really approve of TRUE and FALSE. Why do it? The
semantics of how integers are interpreted are well-defined, so nothing
is wrong with:

bMyDogBitMe = 1;

Why would you want to create an alias for malloc? It is just one more
thing a person checking the program has to verify.

But macros, rather than simple substitutions, and be useful to save
awkward typing.

For example, I've typed this enough times in my career:

for (i=0; i < sizeof(array)/sizeof(array[0]); i++)

So, a macro to handle the computation of the number of elements in the
array ain't so bad.

DTA

[Eric Sosman]

On 5/23/2012 3:56 PM, John Gordon wrote:
> In<4fbd3048$0$1375$4faf...@reader2.news.tin.it> "io_x"<a...@b.c.invalid> writes:
>
>> what about these macro?
>
>> #define MM malloc
>> #define FF free
>> #define ooo cout
>
> How are these useful?

They're too verbose to be useful.

For example, the identifiers `malloc' and `free' are nearly
always followed by the token `(', and malloc is nearly always
preceded by `='. There's thus an obvious improvement on the
first two macros given above:

#define M =malloc(
#define F free(

In the same vein, observe that the argument lists are quite often
followed by semicolons, so a few more definitions become obvious:

#define Z );
#define S sizeof

With these conveniences at hand, we can now write code like

struct f*p M S*p Z
// ... use the struct ...
F p Z

... with the accompanying gains in productivity. The gains are
even more striking in light of the fact that very many statements
end with a function call, so the Z macro has wider applicability:

P "hello, world!\n" Z
E EXIT_FAILURE Z
L jb,42 Z

... and so on. With fifty-two one-letter macro identifiers at
our beck and call, we can look forward to denser code and faster
compilations, since shorter source files can be read more quickly.

The `ooo' macro, though, is silly. There are 52 one-letter
macro names, and 52*(52+1+10)-(26+10) = 3240 two-character names
(we must avoid infringing on 7.31.3's reserved names). With 3292
short names available, there is no reason to waste typing time by
resorting to three-letter identifiers. That's just foolish!

--
Eric Sosman
eso...@ieee-dot-org.invalid

[Kaz Kylheku]

What I think is that Usenet is a last resort for your ilk, who are moderated
out of existence from any properly-run, subscription-based forum.

[Bartc]

"io_x" <a...@b.c.invalid> wrote in message
news:4fbd3048$0$1375$4faf...@reader2.news.tin.it...

The first two are fine, if you think there is something to gain from writing
MM(n) and FF(p) instead of malloc(n) and free(p). (But since they add very
little (they allow malloc/free to be substituted more easily), then probably
not.)

But what's cout? And whatever it is, why is writing ooo better? Why not oo
or just o?

--
Bartc

[Lanarcam]

Object oriented output?

[Ike Naar]

On 2012-05-23, io_x <a...@b.c.invalid> wrote:

No. Too verbose.

[Robert Wessel]

On Wed, 23 May 2012 16:18:30 -0400, David T. Ashley
<das...@gmail.com> wrote:

>The only valid reasons to define a simple preprocessor substitution
>are:
>
>a)When you change one instance, you have to change them all for the
>program to be correct.
>
>b)The constant has a high probability of changing, and you'd like to
>bundle all such things together where they can be changed without
>hunting through the program.
>
>c)Symbolic clarity, i.e. "PI", "MAX_NUMBER_OF_TARGETS", etc.

Of course these categories overlap. Consider the advantages of a
common definition in case the value of pi changes...

[nick_keigh...@hotmail.com]

On Wednesday, May 23, 2012 8:56:06 PM UTC+1, John Gordon wrote:
> In <4fbd3048$0$1375$4faf...@reader2.news.tin.it> "io_x" <a...@b.c.invalid> writes:
>
> > what about these macro?
>
> > #define MM malloc
> > #define FF free
> > #define ooo cout
>
> How are these useful?

this is io_x. he keeps posting stuff like this.

[nick_keigh...@hotmail.com]

On Wednesday, May 23, 2012 9:18:30 PM UTC+1, David T. Ashley wrote:

<snip>

> Macros and constants are overused.

hardly ever

> I've seen some awful things in my career.

#define TWO 50

(to be fair the language actually used didn't have character constants)

> There is nothing wrong with magic numbers, and you can embed them
> directly.

no.

> I've seen nonsense like this:
>
> #define TWICE 2
> for (i=0; i<TWICE; i++) //Read the pushbutton twice, to be sure.
> ...

that's becasue a semantically meaningless name was chosen.

#define BUTTON_REPEAT_COUNT 2

> The only valid reasons to define a simple preprocessor substitution
> are:
>
> a)When you change one instance, you have to change them all for the
> program to be correct.
>
> b)The constant has a high probability of changing, and you'd like to
> bundle all such things together where they can be changed without
> hunting through the program.

how do you know, up front, which constants have a high probability of change? PI isn't going to change, but what about DATA_SEPERATOR, MAXIMUM_TRANSCEIVERS, RETRY_COUNT

> c)Symbolic clarity, i.e. "PI", "MAX_NUMBER_OF_TARGETS", etc.

this is *the* major reason. Semantic clarity.

Suppose these macros have all been replaced with embedded constants.

#define SEPERATOR 9
#define TX_COUNT 9
#define RESPONSE_TIMEOUT 9
#define ALARM_PORT 9

and one of them changes, how do you ensure you change the correct instances?

<snip>

> I frankly don't even really approve of TRUE and FALSE. Why do it? The
> semantics of how integers are interpreted are well-defined, so nothing
> is wrong with:
>
> bMyDogBitMe = 1;

ug. Not just embedded constants but hungarian notation to boot!

<snip>

[Dirk Zabel]

Am 24.05.2012 08:16, schrieb Robert Wessel:
> On Wed, 23 May 2012 16:18:30 -0400, David T. Ashley
> <das...@gmail.com> wrote:

> [...]

> Of course these categories overlap. Consider the advantages of a
> common definition in case the value of pi changes...

YMMD. But do you really prefer looking up the value of pi everytime to a
simple

#include <math.h>
...
area = M_PI * r * r;

;-)

What I really like is:

#define CNEW(type) (type *)malloc(sizeof(type))

so i get a compiler message if i try

pear * pp = CNEW(apple);

while
pear * pp = malloc(sizeof(apple));

will go undetected.

-- Dirk

[Ian Collins]

Which is why people write

pear* pp = malloc(sizeof *pp);

--
Ian Collins

[August Karlstrom]

I prefer these:

#include <gc/gc.h>

#define NEW(p) p = GC_malloc(sizeof *(p))
#define NEW_N(p, n) p = GC_malloc((n) * sizeof *(p))


/August

[David T. Ashley]

On Thu, 24 May 2012 00:29:56 -0700 (PDT),
nick_keigh...@hotmail.com wrote:

>On Wednesday, May 23, 2012 9:18:30 PM UTC+1, David T. Ashley wrote:
>
><snip>
>
>> Macros and constants are overused.
>
>hardly ever
>
>> I've seen some awful things in my career.
>
>#define TWO 50
>
>(to be fair the language actually used didn't have character constants)
>
>> There is nothing wrong with magic numbers, and you can embed them
>> directly.
>
>no.
>
>> I've seen nonsense like this:
>>
>> #define TWICE 2
>> for (i=0; i<TWICE; i++) //Read the pushbutton twice, to be sure.
>> ...
>
>that's becasue a semantically meaningless name was chosen.
>
>#define BUTTON_REPEAT_COUNT 2

OK, you've given it a better name, but why bother with the
preprocessor if the constant is only used in one place? It just
forces the guy reviewing the code to look up one more thing.

"2" is fine, as long as there is a comment there.

>> The only valid reasons to define a simple preprocessor substitution
>> are:
>>
>> a)When you change one instance, you have to change them all for the
>> program to be correct.
>>
>> b)The constant has a high probability of changing, and you'd like to
>> bundle all such things together where they can be changed without
>> hunting through the program.
>
>how do you know, up front, which constants have a high probability of change? PI isn't going to change, but what about DATA_SEPERATOR, MAXIMUM_TRANSCEIVERS, RETRY_COUNT

Nonsense. Everyone writing a program has an intuitive feeling about
what is likely to change and what can change.

By your logic, no "naked" integer or character constants (literals)
would exist, because any of them might change.

I reject that way of thinking.

>> c)Symbolic clarity, i.e. "PI", "MAX_NUMBER_OF_TARGETS", etc.
>
>this is *the* major reason. Semantic clarity.
>
>Suppose these macros have all been replaced with embedded constants.
>
>#define SEPERATOR 9
>#define TX_COUNT 9
>#define RESPONSE_TIMEOUT 9
>#define ALARM_PORT 9
>
>and one of them changes, how do you ensure you change the correct instances?

"Instances" rather than "instance" is the key observation. I cited
this scenario as "(a) When you change one instance, you have to change

them all for the program to be correct".

If there is a single instance, you'd be better off leaving it "naked".

But for multiple instances that need to be consistent ... yeah, I
agree with you.

><snip>
>
>> I frankly don't even really approve of TRUE and FALSE. Why do it? The
>> semantics of how integers are interpreted are well-defined, so nothing
>> is wrong with:
>>
>> bMyDogBitMe = 1;
>
>ug. Not just embedded constants but hungarian notation to boot!

You're clearly a borderline nut case.

You want to overuse the preprocessor but also claim that embedding
type information in the variable name is a bad practice.

Therapy and drugs is what you need.

DTA

[John Gordon]

In <b1c8930e-11b4-4dcc...@googlegroups.com> nick_keigh...@hotmail.com writes:

> > bMyDogBitMe = 1;

> ug. Not just embedded constants but hungarian notation to boot!

I read an article on Hungarian notation and it actually sounded quite
useful in its original form:

http://www.joelonsoftware.com/articles/Wrong.html

[Robert Wessel]

On Thu, 24 May 2012 12:15:16 +0200, Dirk Zabel <za...@riccius-sohn.eu>
wrote:

I've actually made that suggestion in c.l.c.:

http://coding.derkeiler.com/Archive/C_CPP/comp.lang.c/2009-11/msg02546.html

Got the usual knee-jerk (and completely missing the point) "don't cast
malloc!" reply...

[James Kuyper]

It's not missing the point, it's seeing the point quite clearly, and
rejecting it. There are only two possible errors when making a call to
malloc(). The first is that the size is wrong; the type is irrelevant.
The second is failing to check for the possibility of a null return
value. The clc idiom

pp = malloc(count * sizeof *pp);

(or malloc(sizeof *pp) if count is guaranteed to be 1) is sufficient in
itself to avoid the size error. Your alternative

pp = CNEW(pear);

has no advantage over that idiom. If pp is indeed a pear*, it will do
the same thing as the clc idiom. If pp is not a pear*, the clc idiom
will still produce the correct size, without requiring any changes,
while CNEW(pear) will have to be changed.

Can you identify a context in which the clc idiom will tolerate an
incorrect use of malloc(), while CNEW() will not?

[Ben Pfaff]

Dirk Zabel <za...@riccius-sohn.eu> writes:

> What I really like is:
>
> #define CNEW(type) (type *)malloc(sizeof(type))
>
> so i get a compiler message if i try
>
> pear * pp = CNEW(apple);
>
> while
> pear * pp = malloc(sizeof(apple));
>
> will go undetected.

I don't have a problem with your macro (although it only works
with certain types), but:

pear *pp = malloc(sizeof *pp);

works just as well without a need for a special macro.

[Willem]

Ben Pfaff wrote:
) Dirk Zabel <za...@riccius-sohn.eu> writes:
)
)> What I really like is:
)>
)> #define CNEW(type) (type *)malloc(sizeof(type))
)>
)> so i get a compiler message if i try
)>
)> pear * pp = CNEW(apple);
)>
)> while
)> pear * pp = malloc(sizeof(apple));
)>
)> will go undetected.
)
) I don't have a problem with your macro (although it only works
) with certain types), but:
) pear *pp = malloc(sizeof *pp);
) works just as well without a need for a special macro.

#define NEW(pp) (pp)=malloc(sizeof *(pp))

pear *pp;
NEW(pp);


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[Ben Pfaff]

Willem <wil...@toad.stack.nl> writes:

> Ben Pfaff wrote:
> ) I don't have a problem with your macro (although it only works
> ) with certain types), but:
> ) pear *pp = malloc(sizeof *pp);
> ) works just as well without a need for a special macro.
>
> #define NEW(pp) (pp)=malloc(sizeof *(pp))
>
> pear *pp;
> NEW(pp);

If the goal is "write a macro to allocate memory and assign it to
a variable", you have accomplished it. But I think that this
makes code harder to reduce, without a clear benefit.

[August Karlstrom]

On 2012-05-24 22:27, Ben Pfaff wrote:

> Willem<wil...@toad.stack.nl> writes:
>> #define NEW(pp) (pp)=malloc(sizeof *(pp))
>>
>> pear *pp;
>> NEW(pp);
>
> If the goal is "write a macro to allocate memory and assign it to
> a variable", you have accomplished it. But I think that this
> makes code harder to reduce, without a clear benefit.

The clear benefit is that it makes memory allocation simpler and less
error prone. Compare these two statements for instance:

NEW(foo->bar->baz);

foo->bar->baz = malloc(sizeof *(foo->bar->boz));


/August

[Ben Pfaff]

August Karlstrom <fusio...@gmail.com> writes:

> On 2012-05-24 22:27, Ben Pfaff wrote:
>> Willem<wil...@toad.stack.nl> writes:
>>> #define NEW(pp) (pp)=malloc(sizeof *(pp))
>>>
>>> pear *pp;
>>> NEW(pp);
>>
>> If the goal is "write a macro to allocate memory and assign it to
>> a variable", you have accomplished it. But I think that this
>> makes code harder to reduce, without a clear benefit.

"to read", I meant, of course.

> The clear benefit is that it makes memory allocation simpler and less
> error prone. Compare these two statements for instance:
>
> NEW(foo->bar->baz);
>
> foo->bar->baz = malloc(sizeof *(foo->bar->boz));

It would seem so at first glance, but I don't actually see that
sort of error in practice, so I'm suspicious that this really
overcomes the benefit of having code that is easy to read.

[Eric Sosman]

Aren't you overlooking what comes next?

if (foo->bar->bas == NULL) ...
foo->bor->baz->answer = 42;
strcpy(fou->bar->baz->question,
"Life, the Universe -- everything");

In other words, the code will refer to the new pointer at least
three times, usually more. That is, the suggested macro reduces
the number of uses of the pointer from N to N-1, but N >= 3
always, N >= 4 nearly always.

If the pointer is cumbersome to spell, the programmer is very
likely to introduce a new variable anyhow:

struct baz_s *newbaz = foo->bar->baz = malloc(sizeof *newbaz);
if (newbaz == NULL) ...
newbaz->answer = 42;
strcpy(newbaz->question, "Life, the Universe -- everything");

In this pattern, the naive use of the macro would actually *increase*
the number of times the pointer is spelled out:

NEW(foo->bar->baz);
struct baz_s *newbaz = foo->bar->baz;
...

However, the typing-averse programmer is likely to turn it around:

struct baz_s *newbaz;
NEW(newbaz);
foo->bar->baz = newbaz;
...

... and frankly, the macro-less idiom is easier to read. (Especially
if the program also wants `enum ItemCondition { NEW, USED };').

--
Eric Sosman
eso...@ieee-dot-org.invalid

[Martin Shobe]

Really? Why wouldn't the programmer use

struct baz_s * newbaz = NEW(foo->bar->baz);

(Not that I approve of the macro, but lets at least keep the criticisms
legitimate.)

[snip]

Martin Shobe

[Robert Wessel]

Trivially:

pp = malloc(count * sizeof *qq); /* allocates kumquats */

The common C idiom is a mitigation of the lack of type safety of
memory allocation. It makes doing it right easier, but provides no
actual enforcement. It's definitely better to use it than not,
however.

The standard idiom also does not help usages which do not involve
immediate assignments to a pointer. Consider:

int f(pear *pp);
...
f(CNEW(pear)); /* safe */
f(malloc(...)); /* not so much */

IMO, as a practice, attaching a type to an object as soon as it's
created is just good form, and requiring something to be duplicated
(correctly) is just asking for trouble, as sooner or later someone is
going to duplicate and modify a chunk of code and miss one of the
references.

[Eric Sosman]

Kind of rends the veil of opacity, don't you think? The
programmer now needs to know that NEW expands not just to any
old code sequence that allocates memory and assigns to its
argument, but specifically to an expression -- in particular,
to an expression that yields a pointer to the new memory.

Besides, in what you snipped I described how the programmer
would (IMHO) quite likely avoid the naive bloat.


--
Eric Sosman
eso...@ieee-dot-org.invalid

[James Kuyper]

On 05/24/2012 06:05 PM, Robert Wessel wrote:
> On Thu, 24 May 2012 13:05:52 -0400, James Kuyper
> <james...@verizon.net> wrote:
>
>> On 05/24/2012 12:31 PM, Robert Wessel wrote:
>>> On Thu, 24 May 2012 12:15:16 +0200, Dirk Zabel <za...@riccius-sohn.eu>
>>> wrote:

...

It's equally trivial to notice that pp and qq don't match; they're both
part of the same assignment expression. When used in the initialization
of a pointer, CNEW() is equally easy to check. However, in the common
case where a pointer is being set somewhere other than during
initialization, if an error message is triggered, figuring out the right
type requires searching elsewhere:

pp = CNEW(pear); // Is pp a pear*, or a kumquat*?

When the object whose value is being set is foo->bar->baz, finding out
the type pointed at could require searching through a string of header
files; with the clc idiom, getting it right can be done just by looking
at a single assignment expression.

> The standard idiom also does not help usages which do not involve
> immediate assignments to a pointer. Consider:
>
> int f(pear *pp);
> ...
> f(CNEW(pear)); /* safe */
> f(malloc(...)); /* not so much */

The clc idiom is inapplicable to that case - it requires a pointer
expression as an argument of sizeof. CNEW() is not particularly
objectionable in that case, but I would consider it a rare one. I
generally want to do something more like the following:

pp = malloc(sizeof *pp);
if(pp)
f(pp);
else
{
// Error handling
}

Actually, normally, what would be the if-branch in the above code
usually contains a lot more than single function call. I prefer to keep
error handling close to the function call whose failure triggered the
handling, so I would usually reverse the test:

pp = malloc(sizeof *pp);
if(pp == NULL)
{
// Error handling
}
else
{
if(f(pp)!=SUCCESS)
{
// Error handling
}
else
{
// Other stuff

}
}


> IMO, as a practice, attaching a type to an object as soon as it's
> created is just good form,

I agree. With either the clc idiom, or CNEW(), the compiler must
generate code implementing the following sequence of events:

1. call malloc()
2. convert the result of that call to pear*
3. store the result of that conversion in pp

There's not a single event separating step 1 from step 2, whether you
use the clc idiom or CNEW(). That's ASAP as far as I'm concerned.

> ... and requiring something to be duplicated

> (correctly) is just asking for trouble, as sooner or later someone is
> going to duplicate and modify a chunk of code and miss one of the
> references.

That's an argument for

#define NEW(pp) (pp) = malloc(sizeof *(pp))

which has already been discussed. The argument of NEW() only needs to be
changed if the variable name changes. The argument of CNEW() needs to be
changed any time the type changes. I might consider using something like
NEW(), but only if I needed to use it very frequently. However, I'd
probably give it a different name, since it's not as closely analogous
to the 'new' operator in C++ as CNEW() is.

[Martin Shobe]

No, I don't think that. I see absolutely no problem specifying that NEW
return the pointer value assigned to its argument.

>
> Besides, in what you snipped I described how the programmer
> would (IMHO) quite likely avoid the naive bloat.

Would that still hold for those programmers who are using that macro
regularly?

Martin Shobe

[nick_keigh...@hotmail.com]

On Thursday, May 24, 2012 3:06:57 PM UTC+1, David T. Ashley wrote:
> On Thu, 24 May 2012 00:29:56 -0700 (PDT),
> nick_keigh...@hotmail.com wrote:
> >On Wednesday, May 23, 2012 9:18:30 PM UTC+1, David T. Ashley wrote:

> >> Macros and constants are overused.
> >
> >hardly ever

they're distinctly *under-used*

<snip>

> >> There is nothing wrong with magic numbers, and you can embed them
> >> directly.
> >
> >no.

as in, I strongly disagree

> >> I've seen nonsense like this:
> >>
> >> #define TWICE 2
> >> for (i=0; i<TWICE; i++) //Read the pushbutton twice, to be sure.
> >> ...
> >
> >that's becasue a semantically meaningless name was chosen.
> >
> >#define BUTTON_REPEAT_COUNT 2
>
> OK, you've given it a better name, but why bother with the
> preprocessor if the constant is only used in one place?

semantic clarity.

> It just
> forces the guy reviewing the code to look up one more thing.
>
> "2" is fine, as long as there is a comment there.

the define /is/ the comment.

> >> The only valid reasons to define a simple preprocessor substitution
> >> are:
> >>
> >> a)When you change one instance, you have to change them all for the
> >> program to be correct.
> >>
> >> b)The constant has a high probability of changing, and you'd like to
> >> bundle all such things together where they can be changed without
> >> hunting through the program.
> >
> >how do you know, up front, which constants have a high probability of change? PI isn't going to change, but what about DATA_SEPERATOR, MAXIMUM_TRANSCEIVERS, RETRY_COUNT
>
> Nonsense. Everyone writing a program has an intuitive feeling about
> what is likely to change and what can change.

...and they are wrong. I've written highly flexible code that then remained unchanged (or disappeared entirely) and I've hard-coded things that turned out to be tremendously volatile.

> By your logic, no "naked" integer or character constants (literals)
> would exist, because any of them might change.

exactly! You'd hate a review from me! I'll allow 0 and 1 everything else should be in a meaningfully named macro. And why limit this to integers? Floating point constants should also be macroised. And then there's path names and registry variables. Heck, some of these shouldn't be int the code at all- put them in a configuration file (XML if you must)

I sometime stick bools in defines

#define ERASE_WIND TRUE
InvalidateRect(wind, rect, ERASE_WIND);

> I reject that way of thinking.

We'll just have to agree to diagree. I think you are simply wrong and flying in the face of decades (centuries?) of good engineering practice.

read this http://en.wikipedia.org/wiki/The_Elements_of_Programming_Style
first published 1974 but still relevent

reead this http://en.wikipedia.org/wiki/Structure_and_Interpretation_of_Computer_Programs
its for undergraduates but still a good read. It explains what abstraction is all about

> >> c)Symbolic clarity, i.e. "PI", "MAX_NUMBER_OF_TARGETS", etc.
> >
> >this is *the* major reason. Semantic clarity.
> >
> >Suppose these macros have all been replaced with embedded constants.
> >
> >#define SEPERATOR 9
> >#define TX_COUNT 9
> >#define RESPONSE_TIMEOUT 9
> >#define ALARM_PORT 9
> >
> >and one of them changes, how do you ensure you change the correct instances?
>
> "Instances" rather than "instance" is the key observation.

I disagree. This is the same sort of logic that leads people to rufuse to break out a subroutine because "it's only called once". Besides how do you know its only going to be called once?

<snip>

> >> I frankly don't even really approve of TRUE and FALSE. Why do it? The
> >> semantics of how integers are interpreted are well-defined, so nothing
> >> is wrong with:
> >>
> >> bMyDogBitMe = 1;
> >
> >ug. Not just embedded constants but hungarian notation to boot!

the "!" is rougly equivalent to ":-)"

> You're clearly a borderline nut case.

riight so anyone who has a technical disagreement with you is crazy... Most of computer science and software engineering is on my side not yours. I've seen several programming standards that support my view.

I've wasted a fair amount of my programming time debugging code written with rules similar to yours.

> You want to overuse the preprocessor but also claim that embedding
> type information in the variable name is a bad practice.

because the type info will be nearby where the variable was declared. Have looked at any microsoft code? What happens when the type changes does the name? Answer: no not always.

> Therapy and drugs is what you need.

cheap shot. I hope I never have to maintain something you wrote.

[nick_keigh...@hotmail.com]

On Thursday, May 24, 2012 3:23:50 PM UTC+1, John Gordon wrote:
> In <b1c8930e-11b4-4dcc...@googlegroups.com> nick_keigh...@hotmail.com writes:
>
> > > bMyDogBitMe = 1;
>
> > ug. Not just embedded constants but hungarian notation to boot!
>
> I read an article on Hungarian notation and it actually sounded quite
> useful in its original form:
>
> http://www.joelonsoftware.com/articles/Wrong.html

yes I've read Joel's article (nice to read it again!) but he failed to convince me. I think the problems he describes could be handled with stronger typing.

Simonyi Hungarian isn't as evil as Microsoft Hungarian (which is what bMyDogBitMe is) but I still think its fundamnetally wrong-headed.

bMyDogBitMe is a violation of what i call extended third normal form or "Only Code It One Place". The type information is in more than one place. Bad.

See DRY principle

[io_x]

"Bartc" <b...@freeuk.com> ha scritto nel messaggio
news:jpjl37$ad3$1...@dont-email.me...

>
> "io_x" <a...@b.c.invalid> wrote in message
> news:4fbd3048$0$1375$4faf...@reader2.news.tin.it...

>> what about these macro?
>>
>> #define MM malloc
>> #define FF free
>> #define ooo cout
>

> The first two are fine, if you think there is something to gain from writing
> MM(n) and FF(p) instead of malloc(n) and free(p). (But since they add very
> little (they allow malloc/free to be substituted more easily), then probably
> not.)
>
> But what's cout? And whatever it is, why is writing ooo better? Why not oo or
> just o?

"o" could be useful for other...
than write ooo is the same of write o only 2 chars more but, the key in
the keyboard is the same...
than i use F so for free FF...

> --
> Bartc
>

[io_x]

"John Gordon" <gor...@panix.com> ha scritto nel messaggio
news:jpjfcm$ou0$1...@reader1.panix.com...

> In <4fbd3048$0$1375$4faf...@reader2.news.tin.it> "io_x" <a...@b.c.invalid>
> writes:
>

>> what about these macro?
>
>> #define MM malloc
>> #define FF free
>> #define ooo cout
>

> How are these useful?

for the function one always use, the clue is:
less to write and less to read and dispose it good in the page

it is because if one use always these function, these "words"
one understand soon what they means even if they are 1 char long

Note good
i not say these symbols have to be too much...
APL [if i remember well] had that problem
can be < 10 for example...

[nick_keigh...@hotmail.com]

On Friday, May 25, 2012 8:56:04 AM UTC+1, nick_keigh...@hotmail.com wrote:

> bMyDogBitMe is a violation of what i call extended third normal form or "Only Code It One Place". The type information is in more than one place. Bad.
>
> See DRY principle

from somewhere or other:-

"•Don't Repeat Yourself (DRY)
If you have more than one way to express the same thing, at some point the two or three different representations will most likely fall out of step with each other. Even if they don't, you're guaranteeing yourself the headache of maintaining them in parallel whenever a change occurs. And change will occur. Don't repeat yourself is important if you want flexible and maintainable software."

[James Kuyper]

I'm sending a second reply, largely redundant with my first, just
because I've noticed a better way to tie it in with your own remarks.

On 05/24/2012 06:05 PM, Robert Wessel wrote:

...
> ... requiring something to be duplicated

> (correctly) is just asking for trouble, as sooner or later someone is
> going to duplicate and modify a chunk of code and miss one of the
> references.

Yes, and CNEW() requires that you duplicate a type specified elsewhere,
possibly very far from the point where CNEW() is used. The clc idiom
requires duplication of a pointer expression that is right nearby, and
that duplication can easily be automated, as has already been discussed
with the NEW() macro.

--
James Kuyper

[Ike Naar]

On 2012-05-25, io_x <a...@b.c.invalid> wrote:
>
> "John Gordon" <gor...@panix.com> ha scritto nel messaggio
> news:jpjfcm$ou0$1...@reader1.panix.com...
>> In <4fbd3048$0$1375$4faf...@reader2.news.tin.it> "io_x" <a...@b.c.invalid>
>> writes:
>>
>>> what about these macro?
>>
>>> #define MM malloc
>>> #define FF free
>>> #define ooo cout
>>
>> How are these useful?
>
> for the function one always use, the clue is:
> less to write and less to read and dispose it good in the page

Unfortunately, for the casual reader, it's not less to read, but more.
If one reads ''malloc'' then one immediately knows what is meant.
If one reads ''MM'', then one has to search for the definition of ''MM''.

[Robert Wessel]

Basically true, *but* CNEW() checks that you did it correctly. The
common idiom does *not*.

[David T. Ashley]

On Fri, 25 May 2012 00:45:48 -0700 (PDT),
nick_keigh...@hotmail.com wrote:

<SNIP>

>> Therapy and drugs is what you need.
>
>cheap shot. I hope I never have to maintain something you wrote.

You have no idea of the horrors I've seen.

When I have to review code, unless there is a really good reason to
introduce preprocessor symbols, it just makes useless work. In same
cases I've had to examine the preprocessor output ... useless work.

(Abstraction) and (use of the preprocessor) are two very different
topics. Not every macro or preprocessor constant represents
abstraction--most do not.

The "one of" argument is interesting. I seem to remember that in the
early days of subroutines, subroutines were viewed as a code bulk
reduction mechanism rather than an abstraction mechanism. That view
gradually changed.

I'm comfortable using a subroutine for a "one-of" operation (and often
do) because of the abstraction argument. But macros seldom offer the
same level of abstraction (because the interface guarantees are
weaker, and you can place less complexity inside a macro). Most
"one-of" macros are flat out wasted typing.

I've found in watching software developers technically mature--or more
often, fail to mature--that they go through a phase very much like the
level of technical maturity expressed in your posts.

I'd be curious if you have the same point of view in 10 years.

I'm not arguing against all use of preprocessor constants or
macros--I'm just saying that there has to be a good reason for it in
every case.

More is less, and less is more. Terseness, compactness, and
directness are virtues.

DTA

[James Kuyper]

There's only one rather unlikely kind of mistake that you can make with
the clc idiom that can be caught by the CNEW() macro. If you're really
worried about making that kind of error, the NEW() macro removes the
possibility of making it, and therefore the need to check for it.

[io_x]

"Ike Naar" <i...@sverige.freeshell.org> ha scritto nel messaggio
news:slrn3vfsjru...@sverige.freeshell.org...

it is only for the first times
when the eye is accostumated to that, read-write is fast, and dispose
on the page is easier...
but possibly i'm wrong...

[Keith Thompson]

David T. Ashley <das...@gmail.com> writes:
[...]

> You're clearly a borderline nut case.
>

> You want to overuse the preprocessor but also claim that embedding
> type information in the variable name is a bad practice.
>

> Therapy and drugs is what you need.

Consider being less obnoxious.

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

"io_x" <a...@b.c.invalid> writes:
> what about these macro?
>
> #define MM malloc
> #define FF free
> #define ooo cout

Horribly bad.

io_x, take a moment to consider the fact that *nobody* has had anything
good to say about all those little macros you love to use. I won't
repeat the reasons; they've been explained to you before. How likely is
it that you're right and the unanimous opinion of programmers with
centuries of collective experience is wrong?

If you want to program your editor to insert "malloc" when you type
"MM", that's great. If your "MM" macro appears in source code, that's
the end of my interest in reading it.

Think about it.

[David T. Ashley]

Actually, you've identified the right problem but the wrong cause.

Information redundancy causes problems of all types in software
development and engineering in general. There are only two solutions:

a)Find a way to keep the information in only one place, AND/OR

b)Devise tools that either generate all of the redundant information
from a basis set or identify inconsistencies.

Here, I'm using "basis set" in the linear algebra sense, i.e.
http://tinyurl.com/ckcqcc8

If you'd like type information available when you examine individual C
statements (which we all do) but at the same time you claim that it is
redundant to include this information in the variable name, then there
are two obvious solutions:

#1: Per (a) above, change the C language so that a variable's type is
automatically determined from the variable name, i.e. "vardec
bTheDogBitMe;" is equivalent to "BOOLEAN_T bTheDogBitMe;"--that way
the type isn't declared outside of the variable name.

#2: Per (b) above, devise tools that detect inconsistencies that
arise when a variable's type don't match the variable name.

The problem that causes the information redundancy is actually the
definition of the C language, not Hungarian notation.

DTA

[Kenny McCormack]

In article <ln7gw0j...@nuthaus.mib.org>,

Keith Thompson <ks...@mib.org> wrote:
>David T. Ashley <das...@gmail.com> writes:
>[...]
>> You're clearly a borderline nut case.
>>
>> You want to overuse the preprocessor but also claim that embedding
>> type information in the variable name is a bad practice.
>>
>> Therapy and drugs is what you need.
>
>Consider being less obnoxious.

Leader Keith has spoken. All bow down.

--
Religion is regarded by the common people as true,
by the wise as foolish,
and by the rulers as useful.

(Seneca the Younger, 65 AD)

[Kenny McCormack]

In article <ln396oj...@nuthaus.mib.org>,
Keith Thompson <ks...@mib.org> wrote:
...

>io_x, take a moment to consider the fact that *nobody* has had anything
>good to say about all those little macros you love to use. I won't
>repeat the reasons; they've been explained to you before. How likely is
>it that you're right and the unanimous opinion of programmers with
>centuries of collective experience is wrong?

I don't know about that. Copernicus faced similar odds.

Yet, I think we can now agree that he was right and all those people with
centuries of collective experience and the full force and power of the state
at their disposal - were wrong.

--
The motto of the GOP "base": You can't be a billionaire, but at least you
can vote like one.

[nick_keigh...@hotmail.com]

On Friday, May 25, 2012 3:52:54 PM UTC+1, David T. Ashley wrote:
> On Fri, 25 May 2012 00:45:48 -0700 (PDT),

[nick believes pretty well all numeric constants should be hidden behind named constants]

<snip>

> > I hope I never have to maintain something you wrote.
>
> You have no idea of the horrors I've seen.

I've seen a few horrors myself

> When I have to review code, unless there is a really good reason to
> introduce preprocessor symbols, it just makes useless work. In same
> cases I've had to examine the preprocessor output ... useless work.

as long as we're talking about simple constants then I profoundly disagree with your views. You are so wrong.

> (Abstraction) and (use of the preprocessor) are two very different
> topics.

no. Abstraction can be achieved by sensible use of macros. If I was programming in C++ I wouldn't use macros for simple constants. But this is C so we're stuck with macros.

> Not every macro or preprocessor constant represents
> abstraction--most do not.

disagree

> The "one of" argument is interesting. I seem to remember that in the
> early days of subroutines, subroutines were viewed as a code bulk
> reduction mechanism rather than an abstraction mechanism. That view
> gradually changed.

not universally it didn't! People rarely say it out loud (though it's nor unknown) but often it's pretty clear what's going on.

> I'm comfortable using a subroutine for a "one-of" operation (and often
> do) because of the abstraction argument.

ok

> But macros seldom offer the
> same level of abstraction (because the interface guarantees are
> weaker, and you can place less complexity inside a macro). Most
> "one-of" macros are flat out wasted typing.

I think you're having an abstraction failure here. The fact that macros are used to define constants in C programs is simply an implementation detail. The point is to hide magic numbers (or other types) behind semantically meaningful abstractions. That's a large chunk of what programming is about.

> I've found in watching software developers technically mature--or more
> often, fail to mature--that they go through a phase very much like the
> level of technical maturity expressed in your posts.

hard to argue that one! I feel I have achieved a pretty good level of technical maturity- but then I would wouldn't I.

To me your reluctance to use all the abstraction available to you is a sign of technical immaturity.

> I'd be curious if you have the same point of view in 10 years.

I think you under-estimate both my age and my experience...

> I'm not arguing against all use of preprocessor constants or
> macros--I'm just saying that there has to be a good reason for it in
> every case.

yes. And avoiding scattering arbitary numeric values about the code seems like a pretty good reason to me!

> More is less, and less is more. Terseness, compactness, and
> directness are virtues.

up to a point Lord Copper!

Appropriate levels of abstraction are also virtues.

Note that some of the Agile people regard comments as "code smells" (not a term I'm fond of- it means that the code in question is possibly flawed and should be looked over with particular care); why use a magic number and comment it when you could use a sensibly named constant instead?

Taken to extremes your view would limit us to single letter variables.

[nick_keigh...@hotmail.com]

On Friday, May 25, 2012 7:41:53 PM UTC+1, Keith Thompson wrote:
> David T. Ashley <das...@gmail.com> writes:

> > You're clearly a borderline nut case.
> >
> > You want to overuse the preprocessor but also claim that embedding
> > type information in the variable name is a bad practice.
> >
> > Therapy and drugs is what you need.
>
> Consider being less obnoxious.

I know a couple of people who are diagnosed schizophrenics so I tend not to like the casual labelling of people merely because you disagree with them. For all he knows I might be a spas thlid.

[nick_keigh...@hotmail.com]

On Friday, May 25, 2012 8:33:10 PM UTC+1, David T. Ashley wrote:
> On Fri, 25 May 2012 00:56:04 -0700 (PDT),
> nick_keigh...@hotmail.com wrote:
> >On Thursday, May 24, 2012 3:23:50 PM UTC+1, John Gordon wrote:
> >> In <b1c8930e-11b4-4dcc...@googlegroups.com> nick_keigh...@hotmail.com writes:

> >> > > bMyDogBitMe = 1;
> >>
> >> > ug. Not just embedded constants but hungarian notation to boot!

<snip>

> >bMyDogBitMe is a violation of what i call extended third normal form or "Only Code It One Place". The type information is in more than one place. Bad.
> >
> >See DRY principle
>
> Actually, you've identified the right problem but the wrong cause.
>
> Information redundancy causes problems of all types in software
> development and engineering in general. There are only two solutions:
>
> a)Find a way to keep the information in only one place, AND/OR
>
> b)Devise tools that either generate all of the redundant information
> from a basis set or identify inconsistencies.

ok

> Here, I'm using "basis set" in the linear algebra sense, i.e.
> http://tinyurl.com/ckcqcc8

I remember basis sets and linear algebra

> If you'd like type information available when you examine individual C
> statements (which we all do) but at the same time you claim that it is
> redundant to include this information in the variable name, then there
> are two obvious solutions:

yes I have kind of shot myself in the foot here. The Lispers would say attach type information to the values not the variables.

(define var "hello) ; var contains a string
(define var 23) ; var now contains a number

> #1: Per (a) above, change the C language so that a variable's type is
> automatically determined from the variable name, i.e. "vardec
> bTheDogBitMe;" is equivalent to "BOOLEAN_T bTheDogBitMe;"--that way
> the type isn't declared outside of the variable name.

ah FOTRAN IV. If it began with I..N it was an INTEGER otherwise it was a FLOAT

> #2: Per (b) above, devise tools that detect inconsistencies that
> arise when a variable's type don't match the variable name.

#3 don't wrte code that widely separates the type from the variable.

> The problem that causes the information redundancy is actually the
> definition of the C language, not Hungarian notation.

I'm not convinced that well written code has a problem with this and I'm certain hungarian isn't the answer!

[nick_keigh...@hotmail.com]

On Friday, May 25, 2012 7:54:11 PM UTC+1, Keith Thompson wrote:
> "io_x" <a...@b.c.invalid> writes:

> > what about these macro?
> >
> > #define MM malloc
> > #define FF free
> > #define ooo cout
>
> Horribly bad.
>
> io_x, take a moment to consider the fact that *nobody* has had anything
> good to say about all those little macros you love to use.

there comes a point when areguing is pointless. If an argument degenerates to repetition of previously iterated positions then invoke the rule from chess and declare a stalemate. I virtually-plonked io_x some time ago. If he says something vaguely sensible (which he does sometimes) then I'll respond. His silly macros and wads of assembler I just ignore.

> I won't
> repeat the reasons; they've been explained to you before. How likely is
> it that you're right and the unanimous opinion of programmers with
> centuries of collective experience is wrong?
>
> If you want to program your editor to insert "malloc" when you type
> "MM", that's great. If your "MM" macro appears in source code, that's
> the end of my interest in reading it.

ditto

[nick_keigh...@hotmail.com]

On Friday, May 25, 2012 10:35:19 PM UTC+1, Kenny McCormack wrote:
> In article <ln396oj...@nuthaus.mib.org>,
> Keith Thompson <ks...@mib.org> wrote:

> >io_x, take a moment to consider the fact that *nobody* has had anything
> >good to say about all those little macros you love to use. I won't
> >repeat the reasons; they've been explained to you before. How likely is
> >it that you're right and the unanimous opinion of programmers with
> >centuries of collective experience is wrong?
>
> I don't know about that. Copernicus faced similar odds.

"they laughed at Galileo- they also laughed at Bozo the Clown"

> Yet, I think we can now agree that he was right and all those people with
> centuries of collective experience and the full force and power of the state
> at their disposal - were wrong.

yes but most apparently crazy views actually turn out to *be* crazy.

I knew someone who believed you could sharpen a razor blade by placing it under a model of the great pyramid over night.

And someone else who was going to power a car by burning the hydrogen derived from electrolysing water- and thought he'd got a source of free energy.

[Kenny McCormack]

In article <67499309-af3e-4e40...@googlegroups.com>,

<nick_keigh...@hotmail.com> wrote:
>On Friday, May 25, 2012 10:35:19 PM UTC+1, Kenny McCormack wrote:
>> In article <ln396oj...@nuthaus.mib.org>,
>> Keith Thompson <ks...@mib.org> wrote:
>
>> >io_x, take a moment to consider the fact that *nobody* has had anything
>> >good to say about all those little macros you love to use. I won't
>> >repeat the reasons; they've been explained to you before. How likely is
>> >it that you're right and the unanimous opinion of programmers with
>> >centuries of collective experience is wrong?
>>
>> I don't know about that. Copernicus faced similar odds.
>
>"they laughed at Galileo- they also laughed at Bozo the Clown"

Yes, that's a good line! (Definitely a keeper)

It was, in fact, in the back of my mind as I was typing my previous post.

BTW, there is a name for this error that Keith (frequently) makes.

http://en.wikipedia.org/wiki/Appeal_to_the_majority

--

Some of the more common characteristics of Asperger syndrome include:

* Inability to think in abstract ways (eg: puns, jokes, sarcasm, etc)
* Difficulties in empathising with others
* Problems with understanding another person's point of view
* Hampered conversational ability
* Problems with controlling feelings such as anger, depression
and anxiety
* Adherence to routines and schedules, and stress if expected routine
is disrupted
* Inability to manage appropriate social conduct
* Delayed understanding of sexual codes of conduct
* A narrow field of interests. For example a person with Asperger
syndrome may focus on learning all there is to know about
baseball statistics, politics or television shows.
* Anger and aggression when things do not happen as they want
* Sensitivity to criticism
* Eccentricity
* Behaviour varies from mildly unusual to quite aggressive
and difficult

[Martin Ambuhl]

io_x wrote on Wednesday, May 23, 2012 02:50 PM (comp.lang.c):

> what about these macro?
>
> #define MM malloc
> #define FF free
> #define ooo cout

Completely useless.

[Keith Thompson]

nick_keigh...@hotmail.com writes:
> On Friday, May 25, 2012 7:54:11 PM UTC+1, Keith Thompson wrote:
>> "io_x" <a...@b.c.invalid> writes:
>> > what about these macro?
>> >
>> > #define MM malloc
>> > #define FF free
>> > #define ooo cout
>>
>> Horribly bad.
>>
>> io_x, take a moment to consider the fact that *nobody* has had anything
>> good to say about all those little macros you love to use.
>
> there comes a point when areguing is pointless. If an argument
> degenerates to repetition of previously iterated positions then invoke
> the rule from chess and declare a stalemate. I virtually-plonked io_x
> some time ago. If he says something vaguely sensible (which he does
> sometimes) then I'll respond. His silly macros and wads of assembler I
> just ignore.

[...]

I don't disagree, and I generally ignore him myself. But every few
years, if I'm in an overly optimistic mood, I try to reason with the
unreasonable. It rarely works.

[Phil Carmody]

John Gordon <gor...@panix.com> writes:

> In <4fbd3048$0$1375$4faf...@reader2.news.tin.it> "io_x" <a...@b.c.invalid> writes:
>
> > what about these macro?
>
> > #define MM malloc
> > #define FF free
> > #define ooo cout
>

> How are these useful?

For trolling fools into responding, they're almost insurpassable
in usefulness.

Learn how to use a killfile. Most sane people don't want to see io_x's
crap, and that includes when it's quoted in naive responses to it.

Phil
--
> I'd argue that there is much evidence for the existence of a God.
Pics or it didn't happen.
-- Tom (/. uid 822)

[Thad Smith]

On 5/25/2012 4:12 AM, nick_keigh...@hotmail.com wrote:
> On Friday, May 25, 2012 8:56:04 AM UTC+1, nick_keigh...@hotmail.com wrote:
>
>> bMyDogBitMe is a violation of what i call extended third normal form or "Only Code It One Place". The type information is in more than one place. Bad.
>>
>> See DRY principle
>
> from somewhere or other:-

[Pragmatic Programmer by Hunt and Thomas]
>
> "�Don't Repeat Yourself (DRY)

> If you have more than one way to express the same thing, at some point the two or three different representations will most likely fall out of step with each other. Even if they don't, you're guaranteeing yourself the headache of maintaining them in parallel whenever a change occurs. And change will occur. Don't repeat yourself is important if you want flexible and maintainable software."

I read the concept originally in the 1970s as Single Source Definition. I think
it was from Glenford J Meyers, a pioneer in software engineering, but I haven't
verified.

I agree with Nick that using meaningful labels for constants is a useful
abstraction. Macros are a tool. Use them wisely and they will help you.

--
Thad

[nick_keigh...@hotmail.com]

On Tuesday, June 12, 2012 3:30:29 AM UTC+1, Thad Smith wrote:
> On 5/25/2012 4:12 AM, nick_keigh...@hotmail.com wrote:
> > On Friday, May 25, 2012 8:56:04 AM UTC+1, nick_keigh...@hotmail.com wrote:
> >
> >> bMyDogBitMe is a violation of what i call extended third normal form
> >> or "Only Code It One Place". The type information is in more than one
> >> place. Bad.
> >>
> >> See DRY principle
> >
> > from somewhere or other:-
> [Pragmatic Programmer by Hunt and Thomas]
> >

> > "•Don't Repeat Yourself (DRY)

> > If you have more than one way to express the same thing, at some point the two or three different representations will most likely fall out of step with each other. Even if they don't, you're guaranteeing yourself the headache of maintaining them in parallel whenever a change occurs. And change will occur. Don't repeat yourself is important if you want flexible and maintainable software."
>
> I read the concept originally in the 1970s as Single Source Definition. I think
> it was from Glenford J Meyers, a pioneer in software engineering, but I haven't verified.
>
> I agree with Nick that using meaningful labels for constants is a useful
> abstraction. Macros are a tool. Use them wisely and they will help you.

macros can be quite a dangerous tool. Using them to define simple constants
is quite reasonable.

[io_x]

<nick_keigh...@hotmail.com> ha scritto nel messaggio
news:0e4d0a1a-b444-47b6...@googlegroups.com...

On Tuesday, June 12, 2012 3:30:29 AM UTC+1, Thad Smith wrote:
> On 5/25/2012 4:12 AM, nick_keigh...@hotmail.com wrote:
> > On Friday, May 25, 2012 8:56:04 AM UTC+1, nick_keigh...@hotmail.com wrote:
> >
> >> bMyDogBitMe is a violation of what i call extended third normal form
> >> or "Only Code It One Place". The type information is in more than one
> >> place. Bad.
> >>
> >> See DRY principle
> >
> > from somewhere or other:-
> [Pragmatic Programmer by Hunt and Thomas]
> >
> > "�Don't Repeat Yourself (DRY)
> > If you have more than one way to express the same thing, at some point the
> > two or three different representations will most likely fall out of step
> > with each other. Even if they don't, you're guaranteeing yourself the
> > headache of maintaining them in parallel whenever a change occurs. And
> > change will occur. Don't repeat yourself is important if you want flexible
> > and maintainable software."

i'm not agree to above, more rings that find errors there are better it is...