Interface for the libadblockplus API

Here's the interface I came up with. This is just to get us started, a couple of things are missing, like managing custom filters.

Having a single, ambigiously named class as the API is not brilliant, but I think it'll do for now.

Passing the JsEngine instance in is also something I think we'll only have temporarily. I would like to make JsEngine invisible to the client at some point.

We'll also want to add something like Doxygen in the future, but I figured we better wait until we're happy with the API.

[Felix Dahlke, 2013-03-27 08:18:26]

Added some comments.

http://codereview.adblockplus.org/9987009/diff/7002/shell/src/Command.h
File shell/src/Command.h (right):

http://codereview.adblockplus.org/9987009/diff/7002/shell/src/Command.h#newcode1
shell/src/Command.h:1: 
Gosh, missed that. Removed it :)

http://codereview.adblockplus.org/9987009/diff/7002/shell/src/Main.cpp
File shell/src/Main.cpp (right):

http://codereview.adblockplus.org/9987009/diff/7002/shell/src/Main.cpp#newcode73
shell/src/Main.cpp:73: {
This whole block is an unrelated indentation change, I've committed it
separately.

[Oleksandr, 2013-03-27 08:37:01]

http://codereview.adblockplus.org/9987009/diff/1/include/AdblockPlus.h
File include/AdblockPlus.h (right):

http://codereview.adblockplus.org/9987009/diff/1/include/AdblockPlus.h#newcode1
include/AdblockPlus.h:1: #ifndef ADBLOCKPLUS_H
Do you think we could rename this file? To abpv8.h or something like that. We
already have one AdblockPlus.h in IE and I'm sure we have one in each of our
other projects..

http://codereview.adblockplus.org/9987009/diff/3001/src/FilterEngine.cpp
File src/FilterEngine.cpp (right):

http://codereview.adblockplus.org/9987009/diff/3001/src/FilterEngine.cpp#newc...
src/FilterEngine.cpp:33: {
I guess it probably won't be an issue on Linux, but on Windows I always try to
use std:wstring instead. Especially here, where there is almost guaranteed to be
special chars. Would you oppose to going wstring everywhere?

[Felix Dahlke, 2013-03-27 08:59:17]

http://codereview.adblockplus.org/9987009/diff/1/include/AdblockPlus.h
File include/AdblockPlus.h (right):

http://codereview.adblockplus.org/9987009/diff/1/include/AdblockPlus.h#newcode1
include/AdblockPlus.h:1: #ifndef ADBLOCKPLUS_H
On 2013/03/27 08:37:01, Oleksandr wrote:
> Do you think we could rename this file? To abpv8.h or something like that. We
> already have one AdblockPlus.h in IE and I'm sure we have one in each of our
> other projects..

That shouldn't cause any trouble if we don't put include/AdblockPlus in the
include path, but only include. Then we'd have #include
<AdblockPlus/AdblockPlus.h>. Should actually work regardless with
<AdblockPlus.h> I think.

What could cause an issue is the include guard though. I'll prefix them all, but
in a separate review.

http://codereview.adblockplus.org/9987009/diff/3001/src/FilterEngine.cpp
File src/FilterEngine.cpp (right):

http://codereview.adblockplus.org/9987009/diff/3001/src/FilterEngine.cpp#newc...
src/FilterEngine.cpp:33: {
On 2013/03/27 08:37:01, Oleksandr wrote:
> I guess it probably won't be an issue on Linux, but on Windows I always try to
> use std:wstring instead. Especially here, where there is almost guaranteed to
be
> special chars. Would you oppose to going wstring everywhere?

That's tricky actually... std::string works fine for UTF-8 on Linux, but not on
Windows. wstring on Linux on the other hand would store 4 bytes per char. That's
not acceptable for us, as we're dealing with lots of filters.

I'll investigate this. We can ignore it for now if we stick to ASCII URLs,
subscription titles and filters.

[Oleksandr, 2013-03-27 09:04:38]

ok, well. LGTM. Let's roll!
On 2013/03/27 08:59:17, Felix H. Dahlke wrote:
> http://codereview.adblockplus.org/9987009/diff/1/include/AdblockPlus.h
> File include/AdblockPlus.h (right):
> 
>
http://codereview.adblockplus.org/9987009/diff/1/include/AdblockPlus.h#newcode1
> include/AdblockPlus.h:1: #ifndef ADBLOCKPLUS_H
> On 2013/03/27 08:37:01, Oleksandr wrote:
> > Do you think we could rename this file? To abpv8.h or something like that.
We
> > already have one AdblockPlus.h in IE and I'm sure we have one in each of our
> > other projects..
> 
> That shouldn't cause any trouble if we don't put include/AdblockPlus in the
> include path, but only include. Then we'd have #include
> <AdblockPlus/AdblockPlus.h>. Should actually work regardless with
> <AdblockPlus.h> I think.
> 
> What could cause an issue is the include guard though. I'll prefix them all,
but
> in a separate review.
> 
> http://codereview.adblockplus.org/9987009/diff/3001/src/FilterEngine.cpp
> File src/FilterEngine.cpp (right):
> 
>
http://codereview.adblockplus.org/9987009/diff/3001/src/FilterEngine.cpp#newc...
> src/FilterEngine.cpp:33: {
> On 2013/03/27 08:37:01, Oleksandr wrote:
> > I guess it probably won't be an issue on Linux, but on Windows I always try
to
> > use std:wstring instead. Especially here, where there is almost guaranteed
to
> be
> > special chars. Would you oppose to going wstring everywhere?
> 
> That's tricky actually... std::string works fine for UTF-8 on Linux, but not
on
> Windows. wstring on Linux on the other hand would store 4 bytes per char.
That's
> not acceptable for us, as we're dealing with lots of filters.
> 
> I'll investigate this. We can ignore it for now if we stick to ASCII URLs,
> subscription titles and filters.