I'm a little confused concerning when to use ${...} compared to #{...}. Spring's documentation only uses #{...}, but there are plenty of examples that use ${...}. Furthermore, when I started with SpEL I was told to use ${...} and it works fine.
For those who are confused, an example of how I use it would be
#Component
public class ProxyConfiguration {
#Value("${proxy.host}")
private String host;
#Value("${proxy.port}")
private String port;
:
}
and some property file:
proxy.host=myproxy.host
proxy.port=8000
My questions are:
what are the differences or is it the same?
is one version deprecated so I should use the other one?
${...} is the property placeholder syntax. It can only be used to dereference properties.
#{...} is SpEL syntax, which is far more capable and complex. It can also handle property placeholders, and a lot more besides.
Both are valid, and neither is deprecated.
${expr} --> Immediate Evaluation
#{expr} --> Deferred Evaluation
Immediate evaluation means that the expression is evaluated and the result returned as soon as the page is first rendered. Deferred evaluation means that the technology using the expression language can use its own machinery to evaluate the expression sometime later during the page’s lifecycle, whenever it is appropriate to do so.
Complete reference here
There is no JSP EL, JSP uses SpEL. SpEL fits to technology that is using it.
Try reading this article, which suggests
"If the hash is used, your code is recomputed every time that element is included in a partial refresh (i.e. each time it is rendered). If you use a dollar, your code is only computed when the page is initially loaded. But this has been extended beyond just EL, to SSJS too. After the hash or dollar, the curly braces denote the start and end of your language. This will be important when we come to combining languages later."
Expression Language Specification • Final Release - May 8, 2006
Page 2:
An eval-expression is formed by using the constructs ${expr} or #{expr}. Both
constructs are parsed and evaluated in exactly the same way by the EL, even though
they might carry different meanings in the technology that is using the EL.
Related
There are some forms in the tradition of Scheme that are named the same as more primitive forms but with a * appended as a suffix.
Some examples
let*
define*
Now for these derived forms the explanation is that you get visibility of your previous bindings
in the later bindings kind of a letrec style but creating one id at a time instead of all at once (?).
Now this pattern extends thought to other forms and some packages have custom macros with the * symbol as a suffix (define-ratbag*). Is this some implicit convention of the Scheme tribe, is this documented somewhere?
There are several things that a * suffix might mean:
sequential scoping like let*, as opposed to independent scoping like let. Examples: with-syntax* is like with-syntax, but each right-hand side is in the scope of previous clauses.
sequential effect as opposed to independent effect. Examples: parameterize* is like parameterize, but each parameter's new value is evaluated with the previous parameters updated to their new values; with-handlers* is like with-handlers, but each exception handler is called in a context with the previous exception handlers installed.
like the other thing, but multiple times. Examples: remove* is like remove, but removes all occurrences of the given element; regexp-match* is like regexp-match, but finds all matches.
like the other thing, but the final argument acts like a rest-argument. Examples append*, list*: (append* vss) is equivalent to (apply append vss).
like the other thing, but accepts multiple arguments. Examples: hash-set* is like hash-set, but accepts multiple key-value pairs.
like the other thing, but just a bit different. Examples: write-bytes-avail* is like write-bytes-avail, except it never blocks; date* is like date except it adds nanosecond and time-zone-name fields; call-with-input-file* is like call-with-input-file except closes the input port on escapes. In this usage, you can read * as Scheme/Racket's version of a prime suffix.
I'm interested in putting an opening brace for functions (but not if statements and other contexts). For example
void foo()
{
...
}
Flamewars aside, is there a good rationale for not doing this? Although I use same-line open-brackets for if/else and smaller blocks, I think in this case visual organization of larger units of code (functions/methods/classes/structs) can trump perfect consistency.
Moreover, how do I get clang-format to follow this style?
As the documentation says, invoke clang-format with -style=file, and use a .clang-format file placed in an enclosing directory to customize style options. The format style option specifying brace placement is called BreakBeforeBraces. From the docs,
BreakBeforeBraces (BraceBreakingStyle)
The brace breaking style to
use.
Possible values:
BS_Attach (in configuration: Attach) Always attach braces to surrounding context.
BS_Linux (in configuration: Linux) Like Attach, but break before braces on function, namespace and class definitions.
BS_Stroustrup (in configuration: Stroustrup) Like Attach, but break before function definitions, and ‘else’.
BS_Allman (in configuration: Allman) Always break before braces.
BS_GNU (in configuration: GNU) Always break before braces and add an extra level of indentation to braces of control statements, not to
those of class, function or other definitions.
The style that matches your description is BS_Stroustrup. Add the following entry to your .clang-format
BreakBeforeBraces: Stroustrup
In addition to the docs, clangformat.com lists all the options and illustrates many of them with examples.
Pradhan has an excellent answer, but you may find that you get breaks where you do not want them (as I found).
There is another option, "Custom", in at least clang-format versions 3.8 and 5 (I'm using 3.8 and found BS_Custom in the 5 docs). With this, you can specify in BraceWrapping what you want, including an "AfterFunction" option.
In the following example excerpt, I have listed others as true/false since the OP's question only specifies AfterFunction (i.e. "before opening brace of a function"):
BraceWrapping:
AfterClass: true
AfterControlStatement: true
AfterEnum: true/false
AfterFunction: true
AfterNamespace: true/false
AfterObjCDeclaration: true/false
AfterStruct: true/false
AfterUnion: true/false
BeforeCatch: true/false
BeforeElse: true/false
IndentBraces: true/false
BreakBeforeBraces: Custom
I have tested this with my configuration and it gives finer-grained control of brace breaking.
What is the difference between the following lines of (rspec) code and regardless if they are the same or different, when should you use one instead of the other?
book = double("book")
allow(book).to receive(:title) { "The RSpec Book" }
versus
book = double("book")
book.stub(:title).and_return("The RSpec Book")
There are 2 differences but the result is exactly the same. Both are in regards to the rspec mocks/expectations syntax.
Use of #allow instead of #stub method. First case uses the new rspec syntax introduced this year. This is now the preferred way of using rspec. Altough the old syntax isn't deprecated, it will probably be disabled by default in rspec3. More info on this topic from the maintainer of rspec:
http://myronmars.to/n/dev-blog/2012/06/rspecs-new-expectation-syntax
http://myronmars.to/n/dev-blog/2013/07/the-plan-for-rspec-3
Use of block instead of #and_return to define the returning value. This has nothing to do with the mentioned syntax change; both approaches have been available for quite a while (since rspec 1). It is more appropriate to use the #and_return method, since it is (a) the default way, (b) more readable and (c) comes without any runtime overhead. The second approach using block is usually reserved to the corner cases, when you wish to return something of more dynamic nature - not a constant, but some kind of calculation.
The answer to your question would be to use combination of both:
use the #allow instead of #stub
use #and_return instead of block, unless you need to return dynamically calculated value
E.g.:
book = double('book')
allow(book).to receive(:title).and_return('The RSpec Book')
While I am reading page93 $5.1.2 of the C++11 standard, during which it said it is ellegal for you to use the braced-init-list in this case:
auto x=[]{return {1,2}}; //error: a braced-init-list is not an expression
And I have found these two topics, one from the standard and the other from N3681 proposal.
Page397 $14.8.2.5:an initializer list argument causes the parameter to be considered a non-deduced context.
and $7.6.1.4:replacing the occurrences of auto with either a new invented type template parameter U or, if the initializer is a braced-init-list (8.5.4), with std::initializer_list.
While the N3691 proposal suggested "to change a brace-initialized auto to not deduce to an initializer list, and to ban brace-initialized auto for cases where the braced-initializer has more than one element. " and it said "returning a braced-list won't work as it's not an expression"
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3681.html
However, I failed to find "Why is a braced-init-list not an expression？" It may have the same meaning of this topic:
Why can't we have automatically deduced return types?
but there's a little differences while he was trying to understand why the C++ commitee concluded this kind of grammar was worthless. So there must be a particular reason for this?Thank you very much.
Quoting from http://www.stroustrup.com/default-argument.pdf:
The reason that an initializer list isn’t an expression is simply that
we decided (correctly, IMO) not to allow initializer lists on the left
hand side of assignments, as operands of ++, etc. and further decided
(again correctly, IMO) to enforce that through the grammar.
When creating a tracepoint in Visual Studio (right-click the breakpoint and choose "When Hit..."), the dialog has this text, emphasis mine:
You can include the value of a variable or other expression in the message by placing it in curly braces...
What expressions are allowed?
Microsoft's documentation is rather sparse on the exact details of what is and is not allowed. Most of the below was found by trial and error in the Immediate window. Note that this list is for C++, as that's what I code in. I believe in C#, some of the prohibited items below are actually allowed.
Most basic expressions can be evaluated, including casting, setting variables, and calling functions.
General Restrictions
Only C-style casts supported; no static_cast, dynamic_cast, reinterpret_cast, const_cast
Can't declare new variables or create objects
Can't use overloaded operators
Ternary operator doesn't work
Can't use the comma operator because Visual Studio uses it to format the result of the expression; use multiple sets of braces for multiple expressions
Function Calls
Prohibited calls:
Lambdas (can't define or call them)
Functions in an anonymous namespace
Functions that take objects by value (because you can't create objects)
Permitted calls:
Member functions, both regular and virtual
Functions taking references or pointers, to either fundamental or class types
Passing in-scope variables
Using "&" to pass pointers to in-scope variables
Passing the literals "true", "false", numbers
Passing string literals, as long you don't run afoul of the "can't create objects" rule
Calling multiple functions with one tracepoint by using multiple sets of braces
Variable Assignment
Prohibited:
Objects
String literals
Permitted:
Variables with fundamental types, value either from literals or other variables
Memory addresses, after casting: { *(bool*)(0x1234) = true }
Registers: { #eip = 0x1234 }
Use Cases
Calling functions from tracepoints can be quite powerful. You can get around most of the restrictions listed above with a carefully set up function and the right call. Here are some more specific ideas.
Force an if
Pretty straightforward: set up a tracepoint to set a variable and force an if-condition to true or false, depending on what you need to test. All without adding code or leaving the debug session.
Breakpoint "toggling"
I've seen the question a few times, "I need to break in a spot that gets hit a lot. I'd like to simply enable that breakpoint from another breakpoint, so the one I care about only gets breaks from a certain code path. How can I do that?" With our knowledge above, it's easy, although you do need a helper variable.
Create a global boolean, set to false.
Create a breakpoint at your final destination, with a condition to break only when the global flag is true.
Set tracepoints in the critical spots that assign the global flag to true.
The nice thing is that you can move the tracepoints around without leaving the debugging session. Use the Immediate window or the Watch window to reset your global flag, if you need to make another run at it. When you're done, all you need to clean up is that global boolean. No other code to remove.
Automatically skip code
The EIP register (at least on x86) is the instruction pointer. If you assign to it, you can change your program flow.
Find the address of the line you want to skip to by breaking on it once and looking at the value of EIP, either in the Registers window or the Watch window with "#eip,x". (Note that the value in the Registers window is hex, but without the leading "0x".)
Add a tracepoint on the line you want to skip from, with an expression like {#eip = address}, using the address from step 1.
EIP assignment will happen before anything on the line is executed.
Although this can be handy, be careful because skipping code like this can cause weird behavior.
As Kurt Hutchinson says, string assignment is not allowed in a tracepoint. You can get around this by creating a method that assigns the string variable, and call that.
public static class Helper
{
public static void AssignTo(this string value, out string variable)
{
variable = value;
}
}
Then in your tracepoint message:
{"new string value".AssignTo(out stringVariable)}