I'm trying to understand in which cases macro or subroutine is a better idea to use.
For instance, I'm creating a program to parse a huge xml which has hundreds of fields and attribues and I'm defining subroutines and macros to get those nodes, attributes etc. So these subroutines (or macros) are called thousands of times.
Here are example subroutine and macro that I can use;
MACRO
DEFINE xml_get_code_att_2.
node = xml_node_iterator->get_next( ).
while node is not initial.
if lv_lastchild is not initial and node->get_name( ) eq lv_lastchild.
xml_node_iterator = xml_node->create_iterator( ).
exit.
endif.
if node->get_name( ) = &1.
clear: list, nodee.
list = node->get_attributes( ).
nodee = list->get_named_item( 'listID' ).
if nodee is not initial.
&2 = nodee->get_value( ).
endif.
node = xml_node_iterator->get_next( ).
endwhile.
if node is initial.
xml_node_iterator = xml_node->create_iterator( ).
endif.
END-OF-DEFINITION
SUBROUTINE
FORM xml_get_code_att_2 USING p_name CHANGING p_listid
node = xml_node_iterator->get_next( ).
temp = node->get_name( ).
while node is not initial.
if lv_lastchild is not initial and node->get_name( ) eq lv_lastchild.
xml_node_iterator = xml_node->create_iterator( ).
exit.
endif.
if node->get_name( ) = p_name.
clear: list, nodee.
list = node->get_attributes( ).
nodee = list->get_named_item('listID' ).
if nodee is not initial.
p_listid = nodee->get_value( ).
endif.
endif.
node = xml_node_iterator->get_next( ).
endwhile.
if node is initial.
xml_node_iterator = xml_node->create_iterator( ).
endif.
endform.
So which one is better to use?
It is important to understand the difference: Macros are processed at compile time while forms (you're probably better of using methods) are processed at runtime.
As for the advice you asked about: Do not use macros to structure code. Macros are a pain in the a...natomy to debug. Macros are best used to shorten single instructions or short code snippets without branching or loops. For everything else, use methods (or forms, if you have to).
Also, to parse and process XML, you might want to check the existing frameworks and techniques...
MACROS can not be debugged - I would never use MACRos any more. MACROS are some left overs from the former R2 - Host world of SAP.
With macros you can to real ugly things. There is a table trmac where you put macros. You can use these macros in any abap code and drive others gracy if they don't know the TRMAC table. This is realy SAP 80's programming style. Don't do that.
Related
I am working on a project that deals with lots of atomic operations. Till now I didn’t knew about atomic_load() and was only relying on assignment operator to get value of an atomic type and I haven’t seen an error except of so much of testing. Those atomic types are changed by multiple processes and threads as well by atomic_compare_exchange_strong_explicit(), so they will need an old value every time, and that’s where I always did oldValue = <Atomic_ type_variable> and it always works fine.
Is that just by chance? Should I prefer using atomic_load()?
foo = atomic_var is just a shortcut syntax for foo = atomic_load(&atomic_var);
Which itself is a shortcut for foo = atomic_load_explicit(&atomic_var, memory_order_seq_cst); That has a use-case when you want to use an ordering weaker than the default seq_cst.
The main reason for using atomic_load explicitly in your source code is probably to remind human readers that a variable or pointer is atomic. Or maybe as a part of a macro, using atomic_load(&(macro_input)) would create a compile-time error for a non-atomic pointer.
As a "generic" function, you can't take a normal function-pointer to it.
Its existence may be just to make it easier to write the language standard, and explain everything in terms of functions.
It's not the actual assignment that's key here, it's evaluating the atomic variable in an rvalue context (reading it's value as part of an expression, like you typically find on the right-hand side of an =). printf("%d\n", my_atomic_var); is also equivalent to atomic_load.
And BTW, the same thing holds for atomic_var = foo; being exactly the same as atomic_store_explicit with mo_seq_cst. Here it is assignment that's key.
Other kinds of lvalue references to an atomic variable are different, like read-modify-write atomic_var++ is equivalent to atomic_fetch_add.
I am attempting to use LuaJ with Scala. Most things work (actually all things work if you do them correctly!) but the simple task of setting object values has become incredibly complicated thanks to Scala's setter implementation.
Scala:
class TestObject {
var x: Int = 0
}
Lua:
function myTestFunction(testObject)
testObject.x = 3
end
If I execute the script or line containing this Lua function and pass a coerced instance of TestObject to myTestFunction this causes an error in LuaJ. LuaJ is trying to direct-write the value, and Scala requires you to go through the implicitly-defined setter (with the horrible name x_=, which is not valid Lua so even attempting to call that as a function makes your Lua not parse).
As I said, there are workarounds for this, such as defining your own setter or using the #BeanProperty markup. They just make code that should be easy to write much more complicated:
Lua:
function myTestFunction(testObject)
testObject.setX(testObject, 3)
end
Does anybody know of a way to get luaj to implicitly call the setter for such assignments? Or where I might look in the luaj source code to perhaps implement such a thing?
Thanks!
I must admit that I'm not too familiar with LuaJ, but the first thing that comes to my mind regarding your issue is to wrap the objects within proxy tables to ease interaction with the API. Depending upon what sort of needs you have, this solution may or may not be the best, but it could be a good temporary fix.
local mt = {}
function mt:__index(k)
return self.o[k] -- Define how your getters work here.
end
function mt:__newindex(k, v)
return self.o[k .. '_='](v) -- "object.k_=(v)"
end
local function proxy(o)
return setmetatable({o = o}, mt)
end
-- ...
function myTestFunction(testObject)
testObject = proxy(testObject)
testObject.x = 3
end
I believe this may be the least invasive way to solve your problem. As for modifying LuaJ's source code to better suit your needs, I had a quick look through the documentation and source code and found this, this, and this. My best guess says that line 71 of JavaInstance.java is where you'll find what you need to change, if Scala requires a different way of setting values.
f.set(m_instance, CoerceLuaToJava.coerce(value, f.getType()));
Perhaps you should use the method syntax:
testObject:setX(3)
Note the colon ':' instead of the dot '.' which can be hard to distinguish in some editors.
This has the same effect as the function call:
testObject.setX(testObject, 3)
but is more readable.
It can also be used to call static methods on classes:
luajava.bindClass("java.net.InetAddress"):getLocalHost():getHostName()
The part to the left of the ':' is evaluated once, so a statement such as
x = abc[d+e+f]:foo()
will be evaluated as if it were
local tmp = abc[d+e+f]
x = tmp.foo(tmp)
I think the question sums it up pretty well as to what I want: passing the value of a variable to a macro in SystemVerilog.
For example, what I want:
Say, there are 4 signals by the name of abc_X_def and I want to initialize all of them to 0.
So, without macros:
abc_0_def = 4'b0000;
abc_1_def = 4'b0000;
abc_2_def = 4'b0000;
abc_3_def = 4'b0000;
Now, the code that I have written is having a problem:
`define set_value(bit) abc_``bit``_def = 4'b0000
for (int i = 0; i < 4; i++) begin
`set_value(i);
end
The error is that it's trying to find the signal abc_i_def which is obviously wrong. Just wondering if it's possible to pass the actual value of the variable 'i' to the macro.
The preprocessor directives are evaluated by the preprocessor and modify the code that is presented to the compiler.
The for loop is a verilog construct that is evaluated by the compiler.
So your preprocessor is not evaluating the for loop. It sees:
`define `set_value(bit) abc_``bit``_def = 4'b0000
[some verilog]
`set_value(i);
[some verilog]
So 'i' is just i. It doesn't become a number until compilation.
Why don't you use local params with generate, so the local params are created in a loop at elaboration as the for loop is unrolled?
This is one of the many places that macros are a problem. Generate is a problem in other places (like when you want to control port lists).
I dug into this a bit more. Parameters and local parameters inside a generate are created a localparams in the scope of the generate. See here: System Verilog parameters in generate block. I had to get back to work before I could test it.
I would just use code and populate an array. This compiles in VCS:
module veritest
#(
parameter MAX_X = 5,
MAX_Y = 3,
MAX_Z = 2
)
(); // empty port list
logic [4:0] abc_def[1:MAX_X][1:MAX_Y][1:MAX_Z];
always #*
begin
for (integer z=1; z<(MAX_X+1);z=z+1)
for (integer y=1; y<(MAX_Y+1);y=y+1)
for (integer x=1; x<(MAX_X+1);x=x+1)
begin
abc_def[x][y][z] = 4'b0000;
end
end
endmodule
Since you said the naming conventions is out of your control, you should consider using another tool to generate the verilog for you.
You can have the code generated by your preferred programming then use an `include statement in your verilog file. Or you can go with an embedded route.
Perl had EP3 : http://search.cpan.org/~gspivey/Text-EP3-Verilog-1.00/Verilog.pm
Ruby has eRuby : http://www.tutorialspoint.com/ruby/eruby.htm
I'm sure something like it exists for other languages to. Such as Python, Tcl, JavaScript, etc.
Concept is the same, just a difference in embedded language and tool used for conversion.
At my company we've recently been working on a modification to an existing program that used the following logic to perform some database field assignments:
db-buffer1.field1 = if db-buffer1.field1 <> db-buffer2.field2
then db-buffer2.field2
else db-buffer1.field1
I'm not 100% sure of the original programmer's intention here. Can anyone help me understand the value in comparing whether or not the field values are different before deciding whether to assign the new field?
If the comparison is 'false' and we end up assigning db-buffer1.field1 = db-buffer1.field1 do we avoid a write operation on the database?
Also note that this example is part of a larger ASSIGN statement that contains several fields running similar assignment/comparison logic. Does that have any effect on the value of this additional code? (i.e. Do all comparisons in the ASSIGN statement have to succeed in order to avoid a DB write?)
An "IF function" on the right hand side of an expression is a lot like a "ternary operator" in C or Javascript (the "?:" construct).
It only impacts the portion of the ASSIGN that it is part of. When I write code using those I always encase it in parens to make it clear. Like so:
assign
a = ( if x = y then b else c )
z = 2
.
Whether or not a WRITE happens depends a lot on the rest of the code.
Judging only by this snippet you are going to write SOMETHING (at least logically). db-buffer.field1 is going to get a value assigned to it regardless. The IF logic on the right-hand side is just picking if it will be field1 or field2. In the case that boils down to field1 = field1 you might hope that some lower layer will optimize the write out of existence. I don't see your Progress version posted but if it is v9 or better then it may very well be optimized away. (Prior to v9 it would not have been.)
If you really want to "avoid the write" at the application level you should code it like this:
if field1 <> field2 then
assign
field1 = field2
.
This form does not use the IF function, it is just a normal IF ... THEN statement. It is much clearer and it does not depend on optimizations at a lower level. Of course the snippet shown is said to be part of a larger ASSIGN -- so it may or may not be sensible to break it out and write it as I've shown. But it would be worth thinking about.
It appears that the programmer is checking if field1 is not equal to field2 go ahead and update it.
They might as well simply use the following since either way the field is being assigned:
assign db-buffer1.field1 = db-buffer2.field2.
When using the ASSIGN statement (recommended always), from a logical perspective you have to keep in mind that each line is assigned separately.
Tom has a great answer here that gives more information regarding efficiency/history of the ASSIGN statement.
I would be very interested in seeing the rest of the assign statement, but I would also get rid of the if logic in this case as it adds no value, just and extra instruction. As Terry stated above
ASSIGN db-buffer1.field1 = db-buffer2.field2.
While looking through some code, I found two different code snippets for initialization. I don't mean the method names, but the round brackets.
This one has just two of them:
if (self = [super initWithFrame:frame]) {
That's the way I do it all the time, and it seems to work. Now in an Apple example I found this:
if ((self = [super init])) {
Do I have to put it twice into round brackets here? Or is it just fine to put it in one pair of brackets, like the first example?
One pair of brackets is just fine
I call them "paranoia brackets" :)
EDIT: some C/C++ compilers will issue a warning because of the use of the assignment operator (it will say something like "did you mean ==" ?). Using extra parentheses prevents this warning. But XCode doesn't show this kind of warning, so there's no need to do that.
In some languages, if( foo = bar ) implies that the assignment was correctly applied. So the calls:
if( ( foo = bar ) )
would evaluate the assignment and return the result as the outer () act as a LHS, ie,
blah = foo = bar
the outer () act sort of like blah.
In ANSI C and it's children C++ and Objective-C this isn't strictly necessary. However as has been mentioned some compilers will issue a warning since the "=" / "==" type-o can be a nasty one. That type-o led to the idiom of putting the invariant or constant at the left hand side to cause compile time catching of the problem:
if( nil == foo )
if both sides are variables though it's still possibly a mistake.
There is a good reason for doing this even though gcc isn't warning you or evaluating things differently.
If you are writing code in a team environment your peers may not be sure you meant "=" or just mistyped "==", causing them to peer more closely at what you're doing even though there's no need to. In the style of "write once to be read 1000 times" you put in clues to prevent people from having to waste time when reading your code. For instance, use clear and spelled out variable names (no economy on bytes these days!). Don't use obtuse and overly optimized constructs in areas that aren't drags on performance - write your code cleanly.
In this case, use (( )) to indicate you knew it was "=" not "==".
Don't forget, Apple is writing their examples for not just a dozen people to read, but potentially every man, woman, and child on earth to read now and in the future. Clarity is of upmost importance.
Looks like a cut and paste error to me! (Or a lover of Lisp.) There is no good reason to have the second pair of brackets but, as you note, it's not actually harmful.
If I've got this right the first one checks that the assignment self = [super initWithFrame:frame] happens and the second one checks that the result of that assignment is true
But this could just be a lack of tea speaking...