Rust's macro support three forms of call syntax
macro! {...}
macro! (...)
macro! [...]
Can tell which syntax was used to call the macro, from within the macro?
No.
Since I have to enter at least 30 characters: really no. There are no hacks, workarounds, or One Weird Tricks to get around this. It just isn't possible. No one has implemented any way to do it, there's nothing planned, nothing proposed. It's not that it's forbidden or can't be implemented, it just hasn't been.
Related
While debugging abap code I found an interessting code construct.
method_name(: Parameter1 ), Parameter2 ).
As far as I can tell this one calls the method twice. The first time with the first parameter and the second time with the second.
Unfortunately I have no idea how this construct is called and so I can't find any documentation in the SAP docu or with google.
I can tell that this works but is this an official construct?
Does it work with more than two parameters? (E.g. four times)
Best regards,
Dirk
Congratulations, you've found an obscure and most certainly discouraged use of a so-called chained statement. Using this for method calls is not recommended, but since it was once allowed, SAP will be very reluctant to remove this again...
When the ABAP compiler finds a colon, it first expands it blindly without any syntax check (expanding A:B,C,D. into A B. A C. A D.).
And only then it analyses the syntax of each of them - to tell whether it is an assignment, method call or whatever. Pavel
I am attempting to make modifications to an old fortran code to get it to handle a slightly different binary input file format. In the process of doing this I have been encountering * used in a unary fashion. For example, this code found within a loop:
CALL EVENT1(QDRBUF(IPNTR+EVTHSZ),EVTSIZ,EVTID,
- *11000,*10000,*80000)
There are other cases as well but as far as I have seen / remember it is only in function calls. What is this doing?
I'm not a Fortran guy, but this question intrigued me, so I did some looking. It appears to be an alternate return specifier. The number after the asterisk is a label that can be used in place of a normal return, almost like catching an exception.
I'm looking at a piece of very old VB6, and have come across usages such as
Form5!ProgressBar.Max = time_max
and
Form5!ProgressBar.Value = current_time
Perusing the answer to this question here and reading this page here, I deduce that these things mean the same as
Form5.ProgressBar.Max = time_max
Form5.ProgressBar.Value = current_time
but it isn't at all clear that this is the case. Can anyone confirm or deny this, and/or point me at an explanation in words of one syllable?
Yes, Form5!ProgressBar is almost exactly equivalent to Form5.ProgressBar
As far as I can remember there is one difference: the behaviour if the Form5 object does not have a ProgressBar member (i.e. the form does not have a control called ProgressBar). The dot-notation is checked at compile time but the exclamation-mark notation is checked at run time.
Form5.ProgressBar will not compile.
Form5!ProgressBar will compile but will give an error at runtime.
IMHO the dot notation is preferred in VB6, especially when accessing controls. The exclamation mark is only supported for backward-compatibility with very old versions of VB.
The default member of a Form is (indirectly) the Controls collection.
The bang (!) syntax is used for collection access in VB, and in many cases the compiler makes use of it to early bind things that otherwise would be accessed more slowly through late binding.
Far from deprecated, it is often preferable.
However in this case since the default member of Form objects is [_Default] As Object containing a reference to a Controls As Object instance, there is no particular advantage or disadvantage to this syntax over:
Form5("ProgressBar").Value
I agree that in this case however it is better to more directly access the control as a member of the Form as in:
Form5.ProgressBar.Value
Knowing the difference between these is a matter of actually knowing VB. It isn't simply syntactic though, the two "paths" do different things that get to the same result.
Hopefully this answer offers an explanation rather merely invoking voodoo.
Is there any support for debugging xpath user-defined functions in the latest Saxon PE? I've used the trace function, but it seems to work in some contexts and not in others. I'm sure there's a logic to that, but I don't understand it. I'm really looking for something simple like something akin to <xsl:message>.
Thanks in advance.
I suspect your calls on trace() are working, but the output is confusing because of lazy evaluation, which means that things are often evaluated in a different order from what you expect. In fact, the optimizer can sometimes rearrange the expressions you write in your source into something quite different.
Have you tried the debuggers in tools like Stylus Studio or oXygen? Typically these disable some optimizations, making the sequence of execution more comprehensible.
Why didn't C++0x deprecate implicit conversions for user defined types a.k.a. objects? Is there any project which actually uses this (mis)feature? Whenever I see a single argument constructor in a code I get to review or modify I treat it as bug and make it explicit. So far it worked well and nobody complained.
Thank you.
EDIT: Let me quote Alex Stepanov, the creator of STL:
Open your C++ book and read about the
explicit keyword! Also petition your
neighborhood C++ standard committee
member to finally abolish implicit
conversions. There is a common
misconception, often propagated by
people who should know better, that
STL depends on implicit conversions.
Not so!
Reference: A. Stepanov. C++ notes
EDIT AGAIN: No, no debate plz. I am just curious whether anyone uses implicit conversions in their work. I never seen any project which would allow implicit conversion for objects. I thought hard and couldn't come with any hypothetical scenario where implicit conversion wouldn't become a minefield. I mean C++ single argument conversions, not float->double or similar conversions inherited from C.
The obvious answer is that code written and working in C++03 is supposed to continue working with C++0x compilers.
For one thing, it would be a hugely breaking change to remove implicit conversion from the language - even if it were made optional and off-by-default with an implicit keyword.
I've done a search of comp.std.c++ and it doesn't seem to have been discussed at all in that group - though there have been some questions on the subject, no-one seems to have suggested going so far as removing it. I would certainly not go so far either: it's a feature I happily use on occasion and I do not subscribe to making all possibly-converting constructors explicit either - unless it causes real bugs.