If you could change the C or C++ or Java syntax, what would you like different?

[Jon]

If you apply your reasoning to a = a + 1 you will see the problem.

I don't see it.

 

[Seebs]

Think of a new programmer. Is he likely to understand that typedef means
alias in reality or likely to think that it means declaration of a new
type? Therefore, "Alias" is better.

You're making an awful lot of assumptions about other peoples' intuition
here. I would have been more confused by alias than I was by typedef.

See, I learned "alias" from shells, in which it's a *pure* textual
replacement -- more like a C #define than like typedef.

So if you'd called it "alias", then I would have thought that:

alias char * foo;

meant that

foo a, b;

would be EXACTLY identical to

char * a, b;

meaning that b would have been a char, not a pointer-to-char.

The behavior of typedef is not all that much like that of many things
called "aliases", and I think it's better to have an unambiguously new
term, which you can explain, than to overload an old term, which people
may think they know but be mistaken about.

-s

 

[joe]

Did you know that you can use '/' to separate paths in dos/windows
as well? (Well, at least with all compilers I know.)

You can sometimes, but not always (the times you can't escape me).

I don't think it's easy to confuse the meaning of a lone \
at the end of a line with something like "\n".

If the goal is to make parsing trivially easy though, the overloading of
tokens has to go away.

A "contextual analysis by parsers" is not necessary for your "paths
in dos/windows", so we are left with two, rather unambiguous, cases.

Every context where a token shows up has ramifications. I'll bet one can
contrive some incorrect code where having discrete tokens for paths, line
continuations, and escape would have to be considered in a parser.

 

[robertwessel2]

It's a too-overloaded token: dos/windows paths, line continuation,
escape... making for unnecessary contextual analysis by parsers.

Not really. Translation phases 2 and 3 take care of everything, with
minimal context issues. Line continuations are handled in 2,
independently of anything else, and the pre-processor tokenization
process (phase 3) has no ambiguity in dealing with the other uses.

A caveat is that parsing of header names is odd in any event, but is
not made any worse by the possible overloading of backslash.

But the parsing rules for 2 are 3 are pretty simple.

The only significant complication occurs is if you are cross compiling
to an environment with a different character set, then you have to
maintain the escaped characters in constants and string literals
distinctly until phase 5, where the source character set is translated
to the target character set. But that isn't impacted by exactly what
the escape character is.

 

[Willem]

joe wrote:
)
) )> Did you know that you can use '/' to separate paths in dos/windows
)> as well? (Well, at least with all compilers I know.)
)
) You can sometimes, but not always (the times you can't escape me).

When you're executing some old dos commands, which parse / as
a commandline switch flag. Other than that, / is fine.


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

 

[Rui Maciel]

Try it and see. (I meant from the context of complete replacement of C
strings, by working at the library level cannot be done).

What leads you to believe that I, or anyone for that matter, never tried it?


Rui Maciel

 

[Rui Maciel]

Note that string literals in C++ are not std::strings.

A "safe string type" is not necessarily, nor it needs to be, a string literal.


Rui Maciel

 

[Rui Maciel]

Think of a new programmer. Is he likely to understand that typedef means
alias in reality or likely to think that it means declaration of a new
type?

You tell me. What do you believe a "new programmer" understands and does not understand?

Therefore, "Alias" is better.

You have to try to make a case for it before you can claim it is better.


Rui Maciel

 

[Felix Palmen]

If you had written "... but also the standard symbol is used ..." I
would have found it less confusing. Perhaps a language barrier?

Perhaps, at least I didn't expect the placement of a little verb to have
a strong influence on understanding what I wrote. Was it wrongly placed
or just uncommon?

Regards,
Felix

 

[Rui Maciel]

It's a too-overloaded token: dos/windows paths, line continuation,
escape... making for unnecessary contextual analysis by parsers.

Please provide an example of valid C code where the escape character can be confused with what you
describe as "dos/windows paths". And if you have trouble understanding the difference between an
escape token and CPP's line continuation token then I'm afraid you have to deal with much more
serious problems than C's syntax.


Rui Maciel

 

[Rui Maciel]

If the goal is to make parsing trivially easy though, the overloading of
tokens has to go away.

I don't believe anyone can claim that this is a problem to anyone who ever invested some time
writing a compiler.

Every context where a token shows up has ramifications. I'll bet one can
contrive some incorrect code where having discrete tokens for paths, line
continuations, and escape would have to be considered in a parser.

You failed to provide a single example. Are you able to provide any real example that can back up
your statement?


Rui Maciel

 

[Ben Bacarisse]

Think of a new programmer. Is he likely to understand that typedef means
alias in reality or likely to think that it means declaration of a new
type? Therefore, "Alias" is better.

A #define is particularly bad for new programmers -- they need to see
repeated examples of C syntax un-obscured so that the patterns sink in.
If I were specifically targeting people who did not yet know C I'd use a
comment:

/* Define 'Point' as an alias for struct point: */
typedef struct point Point;

Applying your argument to other elements that are not obvious to new
programmers would completely obscure the language (static, const, '*' --
all three uses -- and so on).

 

[Felix Palmen]

Did you know that you can use '/' to separate paths in dos/windows
as well? (Well, at least with all compilers I know.)

The compiler doesn't matter here. Most windows api functions accept '/'
nowadays (but not all). You're better off using '\' for the windows
platform, because there are still cases '/' won't work.

But then, it was Microsoft's awkward decision to use '\' as a path
separator with the rest of the world using '/'. It probably came back on
them the instant they built web functionality (browser, server) in their
OS.

Regards,
Felix

 

[Felix Palmen]

Think of a new programmer. Is he likely to understand that typedef means
alias in reality or likely to think that it means declaration of a new
type? Therefore, "Alias" is better.

And how is typedef NOT declaring a new type? (in fact, it should say
"defining"!) Defining new types is always done by means of existing
types, in any language that allows type definitions.

 

[Tom Anderson]

It's a too-overloaded token: dos/windows paths, line continuation,
escape... making for unnecessary contextual analysis by parsers.

Thanks for the answer. I don't see the problem with its use in Windows
file paths; the solution to that problem, if it is a problem, is simply
not to use Windows.

I don't think the use for both esapes and line continuation is a problem
either, because i think both those functions belong together - they're a
way of writing a string that doesn't correspond exactly to the characters
in the input. Essentially, the escape sequence backslash-newline
represents the empty string.

On the specific point of contextual analysis by parsers, then i'm not
aware that multiple uses of backslash lead to *any* contextual analysis by
the java parser; to it, a backslash always introduces an escape sequence.

tom

 

[Martin Gregorie]

I don't think it's easy to confuse the meaning of a lone \
at the end of a line with something like "\n".

Its not different, just another escape where the escaped character
happens to be invisible. The escaped character is, of course, CR or LF.
The proof of this is that if \ is followed by space or tab it isn't a
line continuation.

 

[Johannes Schaub (litb)]

Please share your oppinion on anything you do not like in the C or C++
or Java syntax (they're quite similar).

In order to maintain the integrity of the discussion (have everything
at the same place) please respond on comp.lang.c.

The first thing I would do is to get rid of "->". Srsly, if the dot operator
is applied on a pointer value p, it will be equivalent to "(*p).mem".

 

[Johannes Schaub (litb)]

You are joking?

Why should I be joking? I regard it as one of the most ugly thing that dot
operator only works on struct and unions.

I see no reasons for "->".

 

[Kenny McCormack]

I see no reasons for "->".

Huh? What language are you talking about? If you dont see the point in
language for -> in C then I am amazed.[/QUOTE]

Now, now. Calm down. Obviously, it won't ever be changed, because C is
what it is.

But the argument, which is valid as far as I can tell, is that the "->"
operator is unnecessary because "." is all you need. I.e., if we were
doing it over from scratch, we could say that whenever we see:

something.member

and the compiler can determine that something is a pointer, then it
would internally convert it to:

something -> member

Since C is a statically typed language, this should work.

And, in fact, if I am reading things that others have posted on the
subject correctly, other languages, like Java, do exactly this.

Finally, note that the basic argument of "If it isn't necessary, then it
is bad" isn't necessarily convincing. Some people have argued that even
if "->" isn't necessary, it is still a good thing, because it makes the
code easier to understand. I.e., it is a "documentation aid".
Personally, I favor this last argument.

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

(Seneca the Younger, 65 AD)

 

[Joshua Cranmer]

It's a too-overloaded token: dos/windows paths, line continuation,
escape... making for unnecessary contextual analysis by parsers.

Nowhere near as overloaded as *, which is used for multiplication,
pointer dereferencing, and declaration of pointer types.

Since paths are not actually handled by a language parser (most of the
time), that only leaves line continuation and escape as a need to
disambiguate. Which is still pretty trivially easy if you look at the
Follow sets (i.e., LL(1)).