How to disable a block of code from compilation and syntactical analysis aka /* <code> */

Help
1

The subject says it (nearly) all:

I want to “multiline comment” (I know, there is no /…/ in Zig) a block of code prepend each and every line with //.

How can I do this?

Cheers!
Tuxic

2

As far as I know, You can not do that. This is because it is easier this way for the parser.

3

I thought about “commenting by code” way, like

if (false) {
    // never executed
}

but, of course, code inside the block must be correct anyway.

2 Likes
4

@dee0xeed gave good advice. Another way is simply to have an editor that can comment out a selection. Single line or multi line won’t make a difference at that point.

2 Likes
5

Hi,

imagine I would have the #define/#ifdef/#undef in a C-code:
#undef DEBUG
#ifdef DEBUG
// chunk of code
#endif
#undef
#define ACCESSREGISTERSDIRECTLY
#ifdef ACCESSREGISTERSDIRECTLY
// chunk code
#endif
#undef
#undef DUMPREGSINLOG
#ifdef
// chunk of code
#endif

and would now get in Zig this instead:
// chunk of code
// chunk of code
// chunk of code

…I assume, the former is more readable, more clear.

The disadvantages of haveing a preprocessore is not due to the preprocessor but is (mis-) use is
the hands of the programmer.
You can write FORTRAN programs in any language.

Only my two cents…

Cheers!
Tuxic

6

There are more considerations than just potential abuse from programmers, like for example tooling support for this kind of stuff. Not having macros of this kind helps simplify syntax highlighters, just to name one example.

1 Like
7

I also have read somewhere it can be easier for the parser, but I didn’t understand why and how: I mean, also with the one-line comment the parser have to handle some “context”. Indeed a comment context starts with a double forward-slash and ends with a newline character. How can it be harder to handle a context that starts with /* and ends with */? Maybe those sequences can be confused with some math with pointers? That of mine is not a criticism, I just want to understand if there can be room for such a feature in the future.

If the issue is with code readability, well, I can write some perfectly unreadable code even without multi-line comments :nerd_face: .

That said, I think that 99% of the code does NOT need multiline comments, as it’s a smell for bad code, but I think that there could be legal cases where a comment is a bit longer or need multiple lines:

  1. because of intrinsic complexity of an algorithm, or
  2. because the comment is intended as a documentation, or
  3. because the comment is intended to explain steps or parts of something

I think that in those cases there is some sense in having all the text in one comment block, instead of having to break the contiguus comment in more blocks

8

This isn’t quite correct, the benefit is that Zig can be tokenized on a line-by-line basis.

It actually doesn’t, the tokenizer can turn a comment into one of three kinds of tokens (normal, doc, top-level doc) before the rest of the parser ever sees it.

That would be true of classic (non-nesting) /* C comments */ as well, making a multi-line token is quite tractable and the single-state tokenizer Zig uses could handle it.

However we’d lose the ability to tokenize on a line-by-line basis, and that’s quite helpful for tasks like regex-based highlighting, grepping, and so on.

Also, just philosophically: everyone wants line-based comments, it would be no fun if Zig were like K&R C which only has the classic style, where you must end a comment explicitly.

Then, if we have one kind of comment already, why have two? It’s extraneous complexity. Zig wants any added complexity to pull its weight, which a second format for comments doesn’t do.

1 Like
9

I am very happy the #ifdef does not exist. That becomes hell in most cases.
btw: what is the maximum line length in Zig code?

11

4294967296 bytes. Although that’s a limitation of the compiler, and whether that limitation will be codified into the language specification is not yet determined.

2 Likes