java - Is there any performance difference between using > and >= in a loop

In loops we keep terminating conditions and we check those conditions in every pass.

I have seen 2 methods to check

1 . i > x or i < x

and the second approch is

2 . i >= x or i <= x

Is there any performance difference in these to 2 approaches while the logical comparison.

Is there any difference in execution time required for both operations. i.e. > and >= ?

Answer

There's very little if any performance difference between these two statements, but there is a significant difference between the two statements and their logic flow.

For instance:

• If you have a loop that runs until i <= 20, you'll loop until i == 20.



• If you have a loop that runs until i < 20, you'll loop until i == 19.

If you have a condition that requires your iteration value to stop before a certain value, be sure that you pick the inequality that most suits it.

By and large, though, if there were any difference in run time or performance on this boolean statement, it would be barely noticeable. One should not base any optimization work around switching out those statements.*

^{*: Also, don't break Rule #1 of Optimization.}

c++ - Sequence Points vs Operator Precedence

I'm still trying to wrap my head around how the following expression results in undefined behavior:

a = a++;

Upon searching SO about this, I found the following question:

Difference between sequence points and operator precedence? 0_o

I read through all the answers but I still am having difficulty with the details. One of the answers describes the behavior of my above code example as ambiguous, in terms of how a is modified. For example, it could come down to either of these:

a=(a+1);a++;
a++;a=a;

What exactly makes a's modification ambiguous? Does this have to do with CPU instructions on different platforms, and how the optimizer can take advantage of the undefined behavior? In other words, it seems undefined because of the generated assembler?

I don't see a reason for the compiler to use a=(a+1);a++;, it just looks quirky and doesn't make much sense. What would possess the compiler to make it behave this way?

EDIT:

Just to be clear, I do understand what is happening, I just don't understand how it can be undefined when there are rules on operator precedence (which essentially defines the order of evaluation of the expression). Assignment happens last in this case, so a++ needs to be evaluated first, to determine the value to assign to a. So what I expect is that a is modified first, during the post-fix increment, but then yields a value to assign back to a (second modification). But the rules for operator precedence seem to make the behavior very clear to me, I fail to find where there is any "wiggle-room" for it to have undefined behavior.

Answer

The first answer in the question you linked to explains exactly what's going on. I'll try to rephrase it to make it more clear.

Operator precedence defines the order of the computation of values via expressions. The result of the expression (a++) is well understood.

However, the modification of the variable a is not part of the expression. Yes, really. This is the part you're having trouble understanding, but that's simply how C and C++ define it.

Expressions result in values, but some expressions can have side effects. The expression a = 1 has a value of 1, but it also has the side effect of setting the variable a to 1. As far as how C and C++ define things, these are two different steps. Similarly, a++ has a value and a side-effect.

Sequence points define when side effects are visible to expressions that are evaluated after those sequence points. Operator precedence has nothing to do with sequence points. That's just how C/C++ defines things.

php - Parse error: syntax error, unexpected '{', expecting '(' help?

I'm trying to make a photo gallery plugin for express engine, yet it's giving me this error and everything seems to close. Any help?

$whats_gonna_happen=$_GET['pictures'];

class upload_pictures
{

    public function upload_pictures
    {
        if (!isset($whats_gonna_happen))
        {
            $uploads='';
            $cout=1;
            $stuff=$this->EE->db->query('SELECT id, name FROM albums');
            $albums_list='';
            while ($row=$stuff->result_array())
            {

                $albums_list .= "" . $row[1] . "\n";
            }  
            mysql_free_result($stuff);
            echo '
            
                
                
                    

                        




                            


                                Choose album : 
                                
                                ' . $albums_list . '
                                
                            
                            

                                
 photo : 
                                
                            
                            


                                Caption : 
                                
                            
                            

                            
                            
                        
                    
                
            

            ';
        }

Answer

The problem is here:

public function upload_pictures

should be:

public function upload_pictures()

javascript - What is the difference between Bower and npm?

What is the fundamental difference between bower and npm? Just want something plain and simple. I've seen some of my colleagues use bower and npm interchangeably in their projects.

Answer

All package managers have many downsides. You just have to pick which you can live with.

History

npm started out managing node.js modules (that's why packages go into node_modules by default), but it works for the front-end too when combined with Browserify or webpack.

Bower is created solely for the front-end and is optimized with that in mind.

Size of repo

npm is much, much larger than bower, including general purpose JavaScript (like country-data for country information or sorts for sorting functions that is usable on the front end or the back end).

Bower has a much smaller amount of packages.

Handling of styles etc

Bower includes styles etc.

npm is focused on JavaScript. Styles are either downloaded separately or required by something like npm-sass or sass-npm.

Dependency handling

The biggest difference is that npm does nested dependencies (but is flat by default) while Bower requires a flat dependency tree (puts the burden of dependency resolution on the user).

A nested dependency tree means that your dependencies can have their own dependencies which can have their own, and so on. This allows for two modules to require different versions of the same dependency and still work. Note since npm v3, the dependency tree will by flat by default (saving space) and only nest where needed, e.g., if two dependencies need their own version of Underscore.

Some projects use both is that they use Bower for front-end packages and npm for developer tools like Yeoman, Grunt, Gulp, JSHint, CoffeeScript, etc.

---

Resources

character - Was Bane part of the League of Shadows during the time Bruce was being trained? - Movies & TV

Both Bruce Wayne and Bane were obviously trained by the League of Shadows so it seems quite possible that their time with the League of Shadows could've coincided.

Bane was in the pit for a long time but had he been rescued from the pit and joined the League of Shadows when Bruce was there?

Why is it bad style to `rescue Exception => e` in Ruby?

Ryan Davis’s Ruby QuickRef says (without explanation):

Don’t rescue Exception. EVER. or I will stab you.

Why not? What’s the right thing to do?

Answer

TL;DR: Use StandardError instead for general exception catching. When the original exception is re-raised (e.g. when rescuing to log the exception only), rescuing Exception is probably okay.

---

Exception is the root of Ruby's exception hierarchy, so when you rescue Exception you rescue from everything, including subclasses such as SyntaxError, LoadError, and Interrupt.

Rescuing Interrupt prevents the user from using CTRLC to exit the program.

Rescuing SignalException prevents the program from responding correctly to signals. It will be unkillable except by kill -9.

Rescuing SyntaxError means that evals that fail will do so silently.

All of these can be shown by running this program, and trying to CTRLC or kill it:

loop do
  begin
    sleep 1
    eval "djsakru3924r9eiuorwju3498 += 5u84fior8u8t4ruyf8ihiure"
  rescue Exception
    puts "I refuse to fail or be stopped!"
  end

end

Rescuing from Exception isn't even the default. Doing

begin
  # iceberg!
rescue
  # lifeboats
end

does not rescue from Exception, it rescues from StandardError. You should generally specify something more specific than the default StandardError, but rescuing from Exception broadens the scope rather than narrowing it, and can have catastrophic results and make bug-hunting extremely difficult.

---

If you have a situation where you do want to rescue from StandardError and you need a variable with the exception, you can use this form:

begin
  # iceberg!

rescue => e
  # lifeboats
end

which is equivalent to:

begin
  # iceberg!
rescue StandardError => e

  # lifeboats
end

---

One of the few common cases where it’s sane to rescue from Exception is for logging/reporting purposes, in which case you should immediately re-raise the exception:

begin
  # iceberg?

rescue Exception => e
  # do some logging
  raise # not enough lifeboats ;)
end

reactjs - Should flux stores, or actions (or both) touch external services?

Should the stores maintain their own state and have the ability to call network and data storage services in doing so ...in which case the actions are just dumb message passers,

-OR-

...should the stores be dumb recipients of immutable data from the actions (and the actions be the ones that fetch/send data between external sources? Store in this instance would act as view-models and would be able to aggregate / filter their data prior to setting their own state base on the immutable data they were fed by the action.

It seems to me that it should be one or the other (rather than a mix of both). If so, why is one preferred / recommended over the other?

Answer

I've seen the flux pattern implemented both ways, and after having done both myself (initially going with the former approach), I believe that stores should be dumb recipients of data from the actions, and that asynchronous processing of writes should live in the action creators. (Async reads can be handled differently.) In my experience, this has a few benefits, in order of importance:

1. Your stores become completely synchronous. This makes your store logic much easier to follow and very easy to test—just instantiate a store with some given state, send it an action, and check to see if the state changed as expected. Furthermore, one of the core concepts in flux is to prevent cascading dispatches and to prevent multiple dispatches at once; this is very difficult to do when your stores do asynchronous processing.




2. All action dispatches happen from the action creators. If you handle asynchronous operations in your stores and you want to keep your stores' action handlers synchronous (and you should in order to get the flux single-dispatch guarantees), your stores will need to fire additional SUCCESS and FAIL actions in response to asynchronous processing. Putting these dispatches in the action creators instead helps separate the jobs of the action creators and the stores; furthermore, you don't have to go digging through your store logic to figure out where actions are being dispatched from. A typical asynchronous action in this case might look something like this (change the syntax of the dispatch calls based on the flavor of flux you're using):

   
   
   

   someActionCreator: function(userId) {
     // Dispatch an action now so that stores that want
     // to optimistically update their state can do so.
     dispatch("SOME_ACTION", {userId: userId});
   
   
     // This example uses promises, but you can use Node-style
     // callbacks or whatever you want for error handling.
     SomeDataAccessLayer.doSomething(userId)
     .then(function(newData) {
       // Stores that optimistically updated may not do anything
       // with a "SUCCESS" action, but you might e.g. stop showing
       // a loading indicator, etc.
       dispatch("SOME_ACTION_SUCCESS", {userId: userId, newData: newData});
     }, function(error) {
       // Stores can roll back by watching for the error case.
   
       dispatch("SOME_ACTION_FAIL", {userId: userId, error: error});
     });
   }
   

   
   
   

   Logic that may otherwise be duplicated across various actions should be extracted into a separate module; in this example, that module would be SomeDataAccessLayer, which handles doing the actual Ajax request.




3. You need less action creators. This is less of a big deal, but nice to have. As mentioned in #2, if your stores have synchronous action dispatch handling (and they should), you'll need to fire extra actions to handle the results of asynchronous operations. Doing the dispatches in the action creators means that a single action creator can dispatch all three action types by handling the result of the asynchronous data access itself.