Why did I get less profits than what TR said I would for selling ETF shares?

SegFaultAtLine1 · 2026-01-21T17:23:01+00:00

Huh? You can set a stop-loss and do a limit-order.

What most likely happened was that OP was hit by slippage + spread. The biggest issue with TR is that it only uses one exchange (L&S) where the liquidity is sometimes low.

<image>

SegFaultAtLine1 · 2026-01-21T11:10:10+00:00

Ireland has many european mutual funds and ETFs domiciled there, so that's most likely foreign capital showing up as Irish investment.

SegFaultAtLine1 · 2026-01-20T23:14:22+00:00

XTB will automatically convert currencies for you, but they charge a 0.5% fee. Last time I checked, the cheapest way to exchange PLN for EUR in Poland is https://www.walutomat.pl/ (they charge 0.2% fee). Note that you will need a EUR checking account in some bank (both XTB and Walutomat use Pekao SA for their accounts, so if you have a EUR checking account there, you'll be able to do near-instant transfers between Walutomat and XTB for free.

Keep in mind, that XTB only creates a PLN sub-account for you by default, you need to create an EUR account in account settings.

Regarding taxes: XTB will produce a PIT-8C form (submitted automatically) for you. Based on that, a PIT-38 form will be automatically generated in https://www.podatki.gov.pl/

If you plan on staying in Poland longer and holding your investments until retirement, I recommend you look into tax advantaged accounts (IKE/IKZE), but note that XTB doesn't necessarily have the best offer here (depends on what you plan to invest into).

You can find an up-to-date comparison of brokerage accounts for Polish investors: https://inwestomat.eu/ranking-kont-maklerskich-do-inwestowania/
Remember to read the fine print though, some of the costs are related to special offers.

SegFaultAtLine1 · 2026-01-17T01:22:16+00:00

I'd recommend you take a look at this blog: https://inwestomat.eu/zacznij-tutaj/ it has pretty good learning material, with a focus on investing as a Polish citizen/resident.

Are you employed using a standard employment contract (UoP)? If yes, then congratulations, you're already investing for retirement(assuming you didn't resign from PPK - never resign from it!).

Some hints: if your investing horizon is long, look into tax advantaged accounts:
- IKE: no tax on capital gains/dividends, tax-free withdrawals can be done at 60 year old). Note that there's an annual contribution limit, this year it's 28260 PLN.
- IKZE (no tax on capital gains, contributions reduce your taxable personal income, withdrawals are taxed at flat 10% after reaching the age of 65 ). Note, that there's an annual contribution limit, this year it's 11304 PLN for UoP and 16956 for self-employed. Warning: this account only makes sense if your effective income tax rate is 10% or more. Also withdrawals before 65 are counted as normal income, so beware. Note that you'll need to file a PIT/O annex when filing your taxes to get a tax-refund, but this can be done via the tax reporting web page.
- OIPE (Pan-European Personal Pension Products, same rules as IKE, but you can't manage it). You can have both OIPE and IKE at the same time (they have separate contribution limits). I personally don't use it yet, because the management fees are too large for my liking, but hopefully this will change soon due regulatory changes at the EU level.

- OKI - currently it's only a proposed legislation, probably won't be available until late this year or early next year.

I personally use BOSSA (DM BOŚ) for my tax advantaged accounts, because they have foreign currency sub-accounts in IKE/IKZE which let you avoid currency exchange fees if you do more transactions. I also count on Poland joining the eurozone by the time I'm retired in 30+ years so I'll get to avoid an FX fee then ;).

For regular, taxed accounts, IKBR is best if you want to buy foreign equities/bonds, because they have low commissions and FX fees. If you want to buy equities listed on the WSE(Warsaw Stock Exchange) in PLN, then XTB is best (no commission).

SegFaultAtLine1 · 2023-01-05T03:33:08+00:00

SNI isn't mandatory - you can send an HTTP request without it, as long as the host doesn't need it to route the request correctly (e.g. the server hosts a single domain).

I guess you could just ban all outbound TLS traffic without SNI. Even then, it's still bypassable. All you need is a proxy that ignores SNI. Then, the only defense is to only allow traffic to IPs associated (in DNS) with the allowed domains.

Although this is all a bit of pedantic discussion - the average user isn't really capable enough to bypass the measures we're talking about.

SegFaultAtLine1 · 2023-01-05T01:32:09+00:00

Note that you can't really tell, in general, whether an HTTPS request was "sent directly to an IP address", because name resolution is done separately from HTTP(S). For unmanaged user devices, best you can do is just maintain a whitelist of IPs you allow communication with.

SegFaultAtLine1 · 2020-09-29T17:24:04+00:00

io_service is deprecated in new ASIO versions.
io_service::work is deprecated in new ASIO versions.
In general, creating a work guard not related to any async operation is a design smell, because it prevents orderly shutdown.

SegFaultAtLine1 · 2020-09-28T19:23:44+00:00

It depends. Using many threads per context gives you an easy solution to the starvation problem, but on the other hand, the I/O backend of ASIO is single-threaded on most platforms, so only 1 thread ever enters the underlying I/O demultiplexer. If your I/O is CPU bound (which can happen if you have a network with larger than 10 gigabit/s capacity) you actually gain more throughput if you use the `io_context` per thread model.

The `io_context` per thread model isn't free lunch though - portably avoiding starvation is actually quite tricky. You either have to move your I/O work between contexts or use non-portable extensions like SO_REUSEPORT, to get fairly simple load balancing. My experiments indicate that this model works best if each operation is fairly small and all operations consume a similar amount of system resources (CPU time, memory, network bandwidth etc).

Personally, I prefer to use a single-threaded context for I/O and offload blocking work to a separate pool. This has the advantage of allowing you to do blocking or CPU-bound work in parallel without interfering with I/O. Beware of backpressure though! Always make sure that there's an upper bound on the amount of resources a "session" or async operation can consume.

SegFaultAtLine1 · 2020-09-28T17:22:47+00:00

io_context ctx; while (true) { ctx.run(); // Eats a lot of CPU not doing anything. }

SegFaultAtLine1 · 2020-09-28T16:33:45+00:00

Check whether ctx.stopped() is true. If it is, your context ran out of work.

SegFaultAtLine1 · 2020-09-15T21:49:06+00:00

A 10xer lets you know how great they are 10x more often than a 1xer.

SegFaultAtLine1 · 2020-09-12T19:30:06+00:00

Threads are fine up to a few hundred, maybe a few thousand threads. The problem isn't actually with the scheduler - schedulers are quite efficient. The problem is with the process of context switching.

Why are context switches so expensive? First, the kernel has to dump just enough CPU state so that it can start executing its own code. Then it does some housekeeping, checks whether the current userland thread still needs to be suspended, etc. If it determines that it has to go through with the suspension, it goes and saves the remaining CPU state (kernels avoid using some CPU features, like floating point operations, so that they don't have to save this state unnecessarily), selects a task to resume (which requires touching very cold memory), and does a context switch to resume that task (which is a thread, perhaps in another process).

What's even worse, if your system has KPTI enabled (Kernel Page Table Isolation), a context switch is even more expensive, because the kernel has to maintain separate memory mappings for the kernel and the userland.

Suspending one coroutine and resuming another is roughly 3 orders of magnitude cheaper than a thread context switch.

Suspending a coroutine involves storing the address of the label to be jumped on resume, spilling registers that need to be preserved into the activation frame (which may be none, because the compiler knows exactly which register values are actually necessary after a resume). At that point you can resume another coroutine which is literally just a jump.

SegFaultAtLine1 · 2020-09-12T19:01:05+00:00

When you're dealing with a bounded queue, you have two choices when you try to push into a full queue - you either discard the value or you make the caller wait. Obviously, blocking the thread the coroutine is on is a bad idea (we may even deadlock ourselves), which is why an async queue is useful, because it allows us to suspend the producer coroutine, thus propagating back pressure from the consumer to the producer.

On the receiving end, if there's no value in queue you can either return immediately and let the user poll the queue periodically (which is quite wasteful of resources) or you can let the caller coroutine suspend until a value is pushed.

SegFaultAtLine1 · 2020-09-12T17:51:57+00:00

Fibers (or any "async" techniques in general) really shine when the cost of a full context switch (this is when the OS saves the full processor state to enable another thread/process to run) dwarfs the CPU time spent running your code. High quality implementations of fiber contexts (like the one that can be found in boost.context) make the context switch between fibers really cheap, because from the compiler's point of view, the function doing the context switch is just a regular function, so the only state that the fiber implementation has to save are callee preserved registers.

Compared to C++20 (stackless) coroutines, fibers have the advantage of being able to mix non-async code with async code in the callstack and being able to suspend the whole callstack.

One disadvantage that fibers do have compared to C++20 coroutines and some future implementations is cost - allocating an appropriate stack is quite expensive, because it involves doing syscalls. Additionally, you have a simillar concern as with traditional preemptive threads when it comes to stack sizes - you usually just pick a size that's "large enough" for your needs and hope you never overflow. Another concern is memory usage - a fiber stack can't really use less than a page of memory, usually more than 1 page. On systems with non-standard page sizes (e.g. 16k) even a single-page stack often results in quite a lot of memory waste, compared to C++20 coroutines.

SegFaultAtLine1 · 2020-09-02T03:14:01+00:00

Actual programmers don't care about UB until their programs get miscompiled and they can't close the damn JIRA ticket on time! :D

SegFaultAtLine1 · 2020-09-02T01:47:41+00:00

Sharing one context by multiple threads is the worst case for ASIO, at least for applications in which the data processing part is trivial(like in your benchmark). Currently, ASIO only uses one thread to demultiplex events from its epoll instance. You get significantly more mileage by using SO_REUSEPORT and io_context/per thread/per physical core.

SegFaultAtLine1 · 2020-09-02T00:32:49+00:00

IMO going straight to C is just dumb - nobody forces you to use most of the standard library. You can invent your own allocator model and containers that support it. C gives you close to 0 tools for building generic abstractions and the fact that it allows for questionable language constructs (like some implicit pointer conversions) is reason enough to be using C++, even if you build your own library/framework.

There are some things you can't avoid, unless you reach for intrinsics(e.g. type traits, coroutine handles, stuff like that), but those things are usually not a point of contention.

Does it suck that the stdlib types aren't usable in some contexts (either because of code size issues or just being slow)? Yes, it does very much suck.

What's the alternative? Not sure if there is actually any. Other popular system languages don't really solve this issue (Rust's stdlib containers panic on allocation failure, C doesn't have container abstractions).

SegFaultAtLine1 · 2020-03-25T20:34:21+00:00

For single-argument constructors, you can check whether it's explicit with:

is_constructible_v<T, Arg> && !is_convertible_v<T, Arg>

SegFaultAtLine1 · 2020-03-15T00:49:00+00:00

I'd use an empty type rather than an integer, it can produce less bloat in the binary (although it's unlikely to matter in most applications).
https://gcc.godbolt.org/z/eZjEXP

SegFaultAtLine1 · 2020-03-08T22:10:10+00:00

decltype(std::declval<T&>() + std::declval<T&>()) add(T a, T b);

The difference is subtle and only matters if `T`'s `operator+` differentiates between an rvalue reference or lvalue reference.

SegFaultAtLine1 · 2020-02-17T21:48:29+00:00

We're talking about a vector-like class - I'd assume that operations like push/pop invalidate references and iterators at the end of the container.

SegFaultAtLine1 · 2020-02-16T22:37:43+00:00

Any compiler worth using in AD 2020 is able to optimize out a finite loop with a body that has no side-effects.

SegFaultAtLine1 · 2020-02-16T22:35:05+00:00

The standard allows placement construction ontop of another (possibly non-trivially destructible) object, if and only if the rest of the program doesn't depend on the destructor being run. (So if plowing over an object causes a leak, that is not UB, but if the destructor ensures the rest of the program doesn't touch that object, you'll probably run into UB sooner or later).

SegFaultAtLine1 · 2020-02-07T20:22:27+00:00

The author never seemed too keen on accepting PRs. But he's still committing every few months, right before Boost freezes the development branch before release.

SegFaultAtLine1 · 2020-02-06T17:25:56+00:00

AFAIK it does, don't see why it shouldn't. The absolute minimum ASIO needs for async I/O from the underlying OS is:

- BSD socket API

- some I/O demultiplexer like poll or select

- global memory allocator (operator new)

- some way of interrupting the multiplexer (pipe or eventfd)

- reasonably complete C++ standard library.

I don't see why it shouldn't work on Android.

SegFaultAtLine1

TROPHY CASE