% # [set a 1] % set a can't read "a": no such variableFrom this, I would assume that comments produce no bytecode, but I'll defer to someone who actually knows. Another quick test is the following:
% proc test1 {args} {} % proc test2 {args} { # This is a long set of comments with [substitions] # of various forms: $args. {} Blah blah blah } % proc test3 {args} { if 0 { This is a long set of comments with [substitutions] of various forms: $args. {} Blah blah blah } } % time test1 100000 1 microseconds per iteration % time test2 100000 27 microseconds per iteration % time test3 100000 28 microseconds per iteration % info patchlevel 8.4.2So, from this it seems that a proc with comments in is not optimized away like the empty proc is. Also, there appears to be little or no difference between a standard comment and an if 0 block, at least for very small tests. Neither proc throws an error (from the bad command name substitutions), so I think neither performs substitutions. I also did a bigger test by using [string repeat] to build up a long comment and then defining the same procs as above, with the longer comment (14000 characters), and the times were roughly equivalent (although the if 0 construct was a couple of microseconds longer each time).
MS answers:
- a proc where (a) the argument list is {args} and (b) the body is all spaces is compiled to just "substitute the arguments (in case there are any side-effects), then push an empty result". Procs where the body consists of comments are not optimised this way, in order to reduce the compile-time overhead. Remember that this optimisation was introduced as a way to allow fast assertions in Tcl.
- all other procs compile "subst and push the arguments, call the proc"
- standard comments compile to strictly nothing
- "if 0 { ... }" compiles to "push an empty result"
time {test2 } 100000Witness the results:
% time test1 100000 1 microseconds per iteration % time test2 100000 25 microseconds per iteration % time test3 100000 21 microseconds per iteration % time {test2 } 100000 4 microseconds per iteration % time {test3 } 100000 4 microseconds per iterationDKF - The if 0 {...} construct does result in bytecodes not being generated for the body, though this doesn't usually make that much difference since the best that you could do would be to skip about two bytecodes...
RS 2013-11-28: Another use for if 0 is a sequence of if/elseif/elseif branches, where you might want to swap the order. In
if {$condA} { ... } elseif {$condB} { ... } elseif {$condC} { ... }it is easy to swap the sequence of condB and condC, by cut & paste in the editor. However, to swap the sequence of condA and condB takes more delting resp. inserting text. If you start this if command with 0, all branches are elseif branches and can be easily rearranged:
if 0 { } elseif {$condA} { ... } elseif {$condB} { ... } elseif {$condC} { ... }AMG: I recently tried this style in C with great success. It was very important because the parts of the if construct were supplied by preprocessor macros, and I didn't want to have a different macro for the first test versus all the subsequent. So instead I had a macro expanding to "if (0)" (expecting the user to supply the trailing semicolon so it resembles a function call).Unfortunately, this triggered an ill-advised warning in the target compiler (not gcc): condition is always false. The customer did not want warnings, and I didn't want to give them warnings, so I had to do something else. I wish I could have instead convinced them to use a better compiler, but they were already in over their head wrangling the GUI IDE visual whatever they had... give them something where they have to (gasp!) type "make", and they would have no hope.