| Marcel Mueller <news.5.maazl@spamgourmet.org>: Apr 20 10:47AM +0200 Am 19.04.19 um 20:58 schrieb Bonita Montero: >> Some string implementations have handling for fast in place storage >> for short strings. > Short stings woulf fit only for very short strings. Reserving unnecessarily large storage for every string (for fixed sized strings) can have a large impact as well. From my experience this is either counterproductive or just a bad workaround for other problems. >> Exactly. And converting strings over and over (with allocations) can >> be much more impact than the optimization gain. > There would be no additional conversions. You just mentioned that library functions will not be compatible to whatever other string implementation you use. This is an issue. >> As long as there is no need to pass /mutable/ strings to library >> functions the use of const char* is the least common denominator. > Maybe, but there are other cases. Memory-allocation is simply slow. It depends. But indeed, the standard allocators of several platforms are not exactly brilliant. >> type for any string implementation. > An overloaded += and other operatoes also wouldn't copy if the capacity > would be suffient. += always requires some copying unless have a rope implementation with immutable fragments. And no rule says that std::string needs to do an extra allocation for every += call. In fact it does not. Of course it cannot estimate the final size of your string. But feel free to call .reserve() to ensure enough space before the concatenation. This is quite close to your requirement, especially the one that requires allocation if the buffer gets too small. It is true that you cannot simply inject an optimized custom allocator into basic_string without breaking type compatibility. But you can reuse an instance for building several strings. The reduces allocations a lot as well. At least if your platforms string implementation supports COW. You are right, std::string is not the optimum for every purpose. But from my point of view it does not mainly lack from an optimized allocator. The main issue is that there is no concept of *immutable strings* as a distinct type in the standard library. Carrying the overhead of mutable strings everywhere in the application is the largest impact. This especially applies in multi-threaded context, i.e almost any application nowadays. A simple base class that consists just of the size and the reference to a data storage could reduce the need for copying a lot. Even COW optimizations (that add further complexity) are now superfluous. Especially different string implementations could provide implicit conversions to that type as long as they use the compatible storage layout. In fact I made the best experience with an immutable, strongly thread safe string class. It uses exactly one storage for every string that consists of the length and the content and a reference counter. Instances of the class are just a pointer to a storage object. Storage objects are shared between instances. Actually these pointers are binary compatible to const char* so a conversion to this type is just a NOP. You can get further gain if you deduplicate identical strings in memory for strings. This can reduce the memory footprint a lot. While saving some memory might not be of primary interest the side effect of significantly higher cache hit rate can give a remarkable gain to application performance. The working set size simply decreases. For relational database applications with many users with typically large redundancy the memory gain can be up to one order of magnitude. The additional effort for deduplication is usually insignificant. It can also avoid the allocation if the factory function already does the deduplication when converting from raw storage. And there is another effect: scalability becomes /below/ linear. The more data you load the higher is the probability that you already have some of its content in memory. But this concept requires /immutability/. It cannot be implemented on top of std::string. So from my point of view the problem with allocations of std::string is mainly a consequence of its mutability. Of course, you always need a second, mutable string class. But this one can use completely different allocation strategies. But if your implementation is smart enough, the storage object behind the string builder class can be the same than the storage object behind the immutable string. So extracting an immutable string from the string builder could be a trivial O(1) operation with no allocation as long as you accept that the string builder is empty afterwards which is the typical use case anyway. On the other side, if you intend to build a large number of strings with different size it could be more helpful to allocate a shared buffer once and reuse it for every string. This buffer could also be on the stack. Now the conversion to an immutable string always requires an allocation (unless you use deduplication of course) but now the creation of the string is likely to cause no more allocations which might be more important. std::string could be used for this purpose if you pass a custom allocator. But you should always convert this to a more compact form when you are done rather than carrying the backpack of mutability and custom allocators everywhere in your application. I have built at least two larger applications that use the above concepts. One in C# which already has an immutable string class and another one in C++ with a custom string class. Both provide very high performance ate quite low memory usage. Loading about 10GB data from an RDBMS implodes to something about 1GB memory. Even several dozen concurrent users create no significant CPU load. And the application does not wait for I/O either, as it mainly operates in memory. Only remote calls to other applications can slow down response times. There are some other deduplication concepts in the application but the largest gain is from strings. Furthermore once you have deduplication other features become quite easy. E.g. if you want to want to provide full versioning in case of changes to objects this now takes almost non memory as new versions of objects likely share most of their properties with the older ones. In fact keeping 5 years of history of really everything did not cause any performance issue at all. And access to this data is transparent. Simply choose date and time and you see an old snapshot of all data including all work items that were post deadline at this point and whatever. Marcel P.S.: There is another thing I do to prevent unnecessary allocations when building strings: printf-like formatting allows the implementation to allocate one final buffer of adequate size. This is impossible if you add compontents with subsequent method calls. So creating an immutable string from a printf like format string is not that bad either. Of course this is not always reasonable. Many platforms provide printf format checking, so UB from the missing type safety could be mostly eliminated. |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 20 11:02AM +0200 > Reserving unnecessarily large storage for every string (for fixed > sized strings) can have a large impact as well. ... Yes, but there are other cases like temporary strings on the stack where my solution could be suitable. Or with strings that usually have a cer- tain size. Or with strings where performance is more important than the waste of space. > You just mentioned that library functions will not be compatible to > whatever other string implementation you use. This is an issue. In this case you won't use my idea. > += always requires some copying unless have a rope implementation with > immutable fragments. += won't have any copying if the capacity of the left string would be sufficient. > You are right, std::string is not the optimum for every purpose. But > from my point of view it does not mainly lack from an optimized allocator. You can't build an allocator with internal storage to replace my idea. I tried this and found that some runtime-libraries additionally allocate storage for debugging-purposes. So allocator can't say which of the allocations is for the characters of the string. |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Apr 20 11:19AM +0200 Am 20.04.19 um 11:02 schrieb Bonita Montero: >> You just mentioned that library functions will not be compatible to >> whatever other string implementation you use. This is an issue. > In this case you won't use my idea. Your idea is not compatible with std::string or did I miss something? >> immutable fragments. > += won't have any copying if the capacity of the left string would be > sufficient. If you compose a string with += /every/ content is copied at least once. ;-) > I tried this and found that some runtime-libraries additionally allocate > storage for debugging-purposes. So allocator can't say which of the > allocations is for the characters of the string. That's true. But where is the problem? If you provide a fixed size storage it is sufficient for /some/ strings. Additional information slightly decrease the maximum string size the storage can hold. no more no less. By the way, I never had any platform that allocated additional storage for debugging purposes /before/ the call to operator new. Of course, operator new does this behind the scenes. Are you sure that the additional storage did not come from a vtable or something like that? You should use POD types for this purpose. Marcel |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 20 01:20PM +0200 >> In this case you won't use my idea. > Your idea is not compatible with std::string or did I miss something? It would be partitially compatible if you overload the global operators. > storage it is sufficient for /some/ strings. Additional information > slightly decrease the maximum string size the storage can hold. no > more no less. I cant recognize if you misunderstood me. There might me more than one allocation from the string-object so that you can't distinguish between the one for the characters and those for whatever. > Are you sure that the additional storage did not come from a vtable > or something like that? ... I don't analyzed the of the runtime-libary. I just wrote an allocator just for fun that allocates in multiples of pages with mmap() of VirtualAlloc() and I found, that some standard-library-implementations additionally allocate a second block with a small size so that my allocator wouldn't fit. But I tested this only with std::vector. |
| Melzzzzz <Melzzzzz@zzzzz.com>: Apr 20 04:11PM > could increase the performance of string-handling significantly. On the > other side, there are many standard-library facilities that only accept > a basic_string so this type of string would be incompatible. You have heard of small string optimisation invented by Andrei Alexandrescu? -- press any key to continue or any other to quit... Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 20 06:17PM +0200 > You have heard of small string optimisation invented by Andrei > Alexandrescu? This might be called a small string optimizatzion not only because of it is optimized for small strings but it also has a small effect since it works only with very small strings. I already said that in the con- ver-ation with Marcel. And I think this is not a good idea to have *generally* such an "optimization" because it generally might have the effect of wasting space. That's also true for my idea, but as you could have noticed also from what I told Marcel I don't think this would be a type of string for special circumstances only. |
| Melzzzzz <Melzzzzz@zzzzz.com>: Apr 20 04:20PM > space. That's also true for my idea, but as you could have noticed > also from what I told Marcel I don't think this would be a type of > string for special circumstances only. Most strings are small. Large ones are rare. You don't place large thing on stack because stack is small usually. -- press any key to continue or any other to quit... Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 20 06:36PM +0200 > Most strings are small. I wouldn't bet on that. And the small string optimization with the glibc++ on 64-bit-systems is only 22 characters. But nevertheless this optimization wouldn't make my idea useless. > Large ones are rare. You don't place > large thing on stack because stack is small usually. The stack is usually extremely large in the user-space. The smallest default stack size of the common operating systems is macOS with 512kB. That's possible because stackspace is overcommitted at least on Unix -systems; on Windows-systems (default stack-size 1MB) the stack pages aren't allocated on construction but subtracted from the pagefile for to guarantee that the stack could theoretically grow to its maximum. |
| Melzzzzz <Melzzzzz@zzzzz.com>: Apr 20 06:21PM > -systems; on Windows-systems (default stack-size 1MB) the stack pages > aren't allocated on construction but subtracted from the pagefile for > to guarantee that the stack could theoretically grow to its maximum. And that's large? -- press any key to continue or any other to quit... Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 20 09:16PM +0200 >> aren't allocated on construction but subtracted from the pagefile for >> to guarantee that the stack could theoretically grow to its maximum. > And that's large? Yes, 1MB stack-size is very large. That would be consumend to a significant extent only when havin massive alloca()s. |
| Melzzzzz <Melzzzzz@zzzzz.com>: Apr 20 07:50PM >> And that's large? > Yes, 1MB stack-size is very large. That would be consumend > to a significant extent only when havin massive alloca()s. Or your strings... -- press any key to continue or any other to quit... Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 20 10:22PM +0200 >> Yes, 1MB stack-size is very large. That would be consumend >> to a significant extent only when havin massive alloca()s. > Or your strings... Even if you end up allocating as much stack space through this kind of "stacticized" strings like in C this wouldn't blow up the stack to its maximum size. |
| Melzzzzz <Melzzzzz@zzzzz.com>: Apr 20 08:32PM > Even if you end up allocating as much stack space through this kind of > "stacticized" strings like in C this wouldn't blow up the stack to its > maximum size. Arrays on stack is always bad idea. -- press any key to continue or any other to quit... Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
| Paavo Helde <myfirstname@osa.pri.ee>: Apr 20 11:32PM +0300 On 20.04.2019 22:16, Bonita Montero wrote: >> And that's large? > Yes, 1MB stack-size is very large. That would be consumend > to a significant extent only when havin massive alloca()s. You must be kidding. A random cat picture from the intertubes is likely more than 1 MB nowaydays. More to the point, there are many problems which could be elegantly solved by recursive algorithms in C++, but technically they cannot because the hardware recursion depth is severely limited, maybe already in the range of thousands or even hundreds of recursions, depending on the algorithm. Been there, seen that, and what's worse, I will be the one who will fix the code (to use heap instead of stack). There is no alloca() around unfortunately, replacing it with std::vector would be an easy fix. |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 20 10:37PM +0200 >> to a significant extent only when havin massive alloca()s. > You must be kidding. A random cat picture from the intertubes is likely > more than 1 MB nowaydays. You won't store this and everything in the size-magnitude of this on the stack. > More to the point, there are many problems which could be elegantly > solved by recursive algorithms in C++, but technically they cannot > because the hardware recursion depth is severely limited, ... This is not a practical boundary since you rarely allocate so much data per recursion-level on the stack. |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 20 10:39PM +0200 >> "stacticized" strings like in C this wouldn't blow up the stack to its >> maximum size. > Arrays on stack is always bad idea. That depends on the size. And if you don't touch the elements of the array yourself but use something like += on on my idea there won't be something like buffer-overflows. |
| "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Apr 20 02:28PM -0700 On 4/19/2019 7:40 AM, Bonita Montero wrote: > could increase the performance of string-handling significantly. On the > other side, there are many standard-library facilities that only accept > a basic_string so this type of string would be incompatible. Use a region allocator? Here is an older one I created: <beware, it uses a hack for alignment...> https://pastebin.com/f37a23918 https://groups.google.com/d/msg/comp.lang.c/7oaJFWKVCTw/sSWYU9BUS_QJ One can break a region allocator apart into sub regions that can be reaped, or even garbage collected... For Bonita: The region can be fed with stack based memory... ;^) |
| Paavo Helde <myfirstname@osa.pri.ee>: Apr 21 12:42AM +0300 On 20.04.2019 23:37, Bonita Montero wrote: >> likely more than 1 MB nowaydays. > You won't store this and everything in the size-magnitude of this on the > stack. And why not? The only problem is the technical limitation. >> because the hardware recursion depth is severely limited, ... > This is not a practical boundary since you rarely allocate so much data > per recursion-level on the stack. One rarely allocates much data on stack because one knows there are technical limitations, and tries to stay clear of them. Even if there is not much data on stack the issue still remains. Let's say I have 4 bytes local data per stack frame, and the stack is 1MB. This means I am limited to ca 250,000 recursions. At the same time my machine has 16 GB of memory, meaning in principle I could have ca 4,000,000,000 recursions instead. Why am I limited to 0.006 % of the machine capabilities? |
| bitrex <user@example.net>: Apr 20 12:50PM -0400 Is there a cleaner way to do this, where I have a Base class with protected or private generic pure virtual function templated on "Param", I have an interface class with a public interface to it, and I have any number of variadic template implementation classes (Bar, in this case) where I can declare multiple overrides for the pure virtual function. I have used the CRTP to "inject" the interface/forwarding template expansion function in class "Base" here. but I'd prefer the virtual function and overrides in Bar to be private but can't figure out how to do that. #include <utility> template <typename Param> class BaseSingle { protected: virtual void BaseFoo(Param) = 0; }; template <typename Derived, typename... Params> class Base : public BaseSingle<Params>... { public: template <typename T> void Foo(T&& x) { static_cast<Derived*>(this)->BaseSingle<T>::BaseFoo(std::forward<T>(x)); } }; template <typename... Params> class Bar : public Base<Bar<Params...>, Params...> { protected: void BaseFoo(int x) override {} void BaseFoo(char x) override {} }; int main() { Bar<int, char> bar; bar.Foo('a'); bar.Foo(42); } On Compiler Explorer for the MSP430 this compiles to (-std=c++11 -Os -fno-rtti -fno-threadsafe-statics): Bar<int, char>::BaseFoo(int): PUSHM.W #1, R4 MOV.W R1, R4 POPM.W #1, r4 RET Bar<int, char>::BaseFoo(char): PUSHM.W #1, R4 MOV.W R1, R4 POPM.W #1, r4 RET non-virtual thunk to Bar<int, char>::BaseFoo(char): PUSHM.W #1, R4 MOV.W R1, R4 POPM.W #1, r4 RET main: PUSHM.W #1, R4 MOV.W R1, R4 SUB.W #4, R1 MOV.W #vtable for Bar<int, char>+4, -4(R4) MOV.W #vtable for Bar<int, char>+12, -2(R4) MOV.B #97, R13 MOV.W R4, R12 ADD.W #-2, R12 CALL #_ZN10BaseSingleIcE7BaseFooEc MOV.B #6, R13 MOV.W R4, R12 ADD.W #-4, R12 CALL #_ZN10BaseSingleIiE7BaseFooEi MOV.B #0, R12 ADD.W #4, R1 POPM.W #1, r4 RET vtable for Bar<int, char>: .short 0 .short 0 .short Bar<int, char>::BaseFoo(int) .short Bar<int, char>::BaseFoo(char) .short -2 .short 0 .short non-virtual thunk to Bar<int, char>::BaseFoo(char) |
| David Brown <david.brown@hesbynett.no>: Apr 20 02:43PM +0200 I was recently working on a class where I wanted a number of bits and pieces calculated at compile time, using members of the class. This is (obviously) not the actual code, but it shows the same effect: class A { static constexpr int next(int x) { return x + 1; } static constexpr const int one = next(0); }; It seems that it is illegal to initialise the constexpr object "one" using the function "next", because the definition of "next" is not considered complete until the end of class A. It is fine to have these two definitions outside a class. It is also fine to write: class A { static constexpr int next(int x) { return x + 1; } static const int one; }; constexpr const int A::one = next(0); Does anyone know any reason for why the first version within the class is not allowed? Are there any other ways to get the same results? The second version works fine, but it splits up the definitions in a way that didn't fit the flow of the code I was writing. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 20 02:53PM +0200 On 20.04.2019 14:43, David Brown wrote: > Are there any other ways to get the same results? The second version > works fine, but it splits up the definitions in a way that didn't fit > the flow of the code I was writing. First, consider using `std::next` ;-) nonstd::next, re the problem, consider having at namespace scope constexpr int next(int x); constexpr const int one = next(0); constexpr int next(int x) { return x + 1; } This reproduces the problem with ordinary functions. It's invalid code. So I guess that even the rules for `constexpr` members effectively implement the conceptual view that in-class-definition class member function bodies are compiled as if they were moved to after the class. It's a nice view, it explains most everything that can baffle a novice about in-class-definition member functions. I didn't know that it also explains `constexpr` member behavior. Thanks. Cheers!, - Alf |
| David Brown <david.brown@hesbynett.no>: Apr 20 04:05PM +0200 On 20/04/2019 14:53, Alf P. Steinbach wrote: >> works fine, but it splits up the definitions in a way that didn't fit >> the flow of the code I was writing. > First, consider using `std::next` ;-) It's getting steadily harder to pick names that don't coincide with the standard library! It's just an example function name - no relation to std::next. > constexpr const int one = next(0); > constexpr int next(int x) { return x + 1; } > This reproduces the problem with ordinary functions. It's invalid code. Yes, that is because you are trying to use the constexpr function (to initialise "one") before it is defined. > It's a nice view, it explains most everything that can baffle a novice > about in-class-definition member functions. I didn't know that it also > explains `constexpr` member behavior. Thanks. That sounds like a way to understand the rules. In my case, the constexpr is actually fully defined before it is used - but because it is in a class that is not yet completed, the function definition is not considered complete either. I can appreciate that that this might not be the case. In particular, functions that depend on the class itself could not be considered "fully defined" until the class is fully defined - data members could be added after the definition, for example. So perhaps the rules of when the functions can be used are made to give a simple and consistent view, rather than a more complex set of rules about what is and is not allowed. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 20 04:42PM +0200 On 20.04.2019 16:05, David Brown wrote: > In my case, the constexpr is actually fully defined before it is used - > but because it is in a class that is not yet completed, the function > definition is not considered complete either. I don't buy that as a technical explanation, and I don't think it's a good conceptual view (because it doesn't explain anything else, it's just a special case arbitrary rule). The ordinary conceptual view of a compiler's rewrite where it moves the member function definitions to after the class, fits too well. That is, it fits everything I know. > So perhaps the rules of when the functions can be used are made to give > a simple and consistent view, rather than a more complex set of rules > about what is and is not allowed. Yes. Cheers!, - Alf |
| blt_4ks0xpw@um7ygq6ykv2ca0gs.edu: Apr 20 03:35PM On Sat, 20 Apr 2019 14:43:16 +0200 > static const int one; >}; >constexpr const int A::one = next(0); I don't really see the point of these syntatic games that constexpr allows. If its a constant expression then by definition you know the value when you write the code so why not just have "static const int one = 1"? |
| LUIGI ROTUNNO GRUPO LA TORRE-IMOPLANET <megliomortochearreso@protonmail.com>: Apr 19 04:25PM -0700 UN TESTO DICENTE ASSOLUTE VERITA'. DA PARTE DEL MIO PREFERITO SWISS BANKER: ANDREAS NIGG. A PROPOSITO DEL CRIMINALE PEDOFILO ED ASSASSINO PAOLO BARRAI. CHE QUI IN BRASILE HO FATTO FINIRE IN CARCERE, ANCHE ( MA NON SOLO) PER PEDERASTIA. PER AVER SODOMIZZATO BAMBINI DI 8, 10 ANNI. FATE UN PO' VOI, PLEASE. LUIGI ROTUNNO. PORTO SEGURO. BRAZIL. TORINO (GRUPPO FCA). ITALY. A VOI L'OTTIMO TESTO A PROPOSITO. E' UN ASSASSINO PEDERASTA: PAOLO BARRAI (TWITTER)! NOTO IN TUTTO IL MONDO COME IL ^PEDOFILO NDRANGHETISTA DEL BITCOIN^)! https://twitter.com/megliomortiche1 OLTRE CHE NOTO RICICLA SOLDI MAFIOSI! ED E' TANTO QUANTO UN COCAINOMANE PAZZO E MANIACO FACENTE FILM PORNO EFFETTUANDO SESSO ORALE CON CAVALLI: PAOLO PIETRO BARRAI, NATO A MILANO IL 28.6.1965 ( NON PER NIENTE E' NOTISSIMO IN TUTTO IL MONDO COME " CCC CIUCCIA CAZZI DI CAVALLO PAOLO BARRAI")! OLTRE CHE LADRO, TRUFFATORE, SEMPRE FALSO, INCAPACISSIMO IN BORSA, AZZERANTE I RISPARMI DI TUTTI E SEMPRE! OLTRE A STRA ESSERE UN NAZI-ST-ALKER VIA INTERNET, AIZZATORE DI SUICIDI, MANDANTE DI OMICIDI, E TORTURATORE OMICIDA! OLTRE AD ESSERE STATO GIA' "SOLO" 3 VOLTE IN CARCERE" ( IN UN PRIMO CASO, A SEGUITO DI ENORMI CRIMINALISSIME FRODI CHE EFFETTUAVA IN CITIBANK, COME DA FINALE DI QUESTO ARTICOLO https://ricerca.repubblica.it/repubblica/archivio/repubblica/2001/02/19/maxi-evasione-da-400-miliardi-terenzio-sotto-torchio.html PER POI CONOSCERE ALTRA GALERA ANCHE IN BRASILE E PURE PER PEDOFILIA OMOSESSUALE http://www.rotadosertao.com/noticia/10516-porto-seguro-policia-investiga-blogueiro-italiano-suspeito-de-estelionato http://noticiasdeportoseguro.blogspot.be/2011/03/quem-e-pietro-paolo-barrai.html http://www.geraldojose.com.br/mobile/?sessao=noticia&cod_noticia=13950 http://www.jornalgrandebahia.com.br/2011/03/policia-civil-de-porto-seguro-investiga-blogueiro-italiano-suspeito-de-estelionato/ http://www.devsuperpage.com/search/Articles.aspx?hl=en&G=23&ArtID=301216 http://www.rotadosertao.com/images/fotos/fotos_noticias/testao.jpg https://pbs.twimg.com/media/CIB3862WcAA8F7c.png ). OLTRE AD ESSERE STATO MEGA MULTATO DA CONSOB, PER " APPENA APPENA" 70.000 EURO, PER MEGA FRODI CHE FACEVA A PROPOSITO DEL FOTOVOLTAICO http://www.bluerating.com/banche-e-reti/33345/qmultaq-da-70mila-euro-per-un-ex-promotore-che-ha-violato-gli-obblighi-informativi http://www.advisoronline.it/albo/consob/22190-consob-sanziona-a-raffica.action https://complaintwire.org/complaint/6K334yHuHw8/mercato-libero-paolo-barrai EFFETTUA TUTTI QUESTI MOSTRUOSISSIMI CRIMINI INSIEME -AL NOTO FIDUCIARIO DI MAFIA, CAMORRA E NDRANGHETA: OLIVER CAMPONOVO https://valori.it/banche-politica-blogger-tutti-gli-affari-dietro-le-cripto-elvetiche/ https://valori.it/chiasso-dove-riciclatori-ndrine-e-criptovalute-sincontrano/ https://www.rsi.ch/la1/programmi/informazione/falo/Bella-gente-10423994.html https://www.corrieredellacalabria.it/cronaca/item/141842-il-riciclaggio-delle-cosche-in-svizzera-facevano-tutti-cosi/ https://www.ilfattoquotidiano.it/2018/05/17/ndrangheta-e-riciclaggio-in-canton-ticino-cosi-fan-tutti-un-fiduciario-si-confessa-alla-tv-svizzera/4360372/ http://www.areaonline.ch/La-storia-del-fiduciario-ticinese-di-fiducia-della-ndrangheta-29f7ee00 http://ilpunto-borsainvestimenti.blogspot.com/2017/10/cryptopolis-il-debutto-di-un-figlio.html - AL PORCO BRUCIA RISPARMI, RICICLA SOLDI MAFIOSI: FEDERICO IZZI DI ROMA (CRIMINALISSIMO TRADER ZIO ROMOLO) https://in.memory.of.e.tern.al/comp.lang.tcl/thread/4226231 - AL NOTO SATANISTA, LADRONE, TRUFFATORE, PEDOFILO ECONOMISTA PAOLO CARDENÁ DI CRIMINALISSIMO BLOG VINCITORI E VINTI https://www.py.cz/pipermail/python/2017-September/013036.html - AL NOTO AVVOCATO PEDERASTA ED ASSASSINO DANIELE MINOTTI DI RAPALLO E GENOVA https://grokbase.com/t/python/python-list/148jckyh1w/avvocato-pedofilomosessuale-ed-assassino-daniele-minotti-facebook-oltre-che-nazi-megalava-euro-mafiosi-e-come-detto-mandante-di-omicidi-o-suicidate-stalker-di-eroe-civile-michele-nista-su-ordine-di-tiranno-fasciocamorrista-silvio-berlusconi - AL NOTO PEDOFILO OMOSESSUALE E KU KLUK KLANISTA, NAZISTISSIMO GIACOMO ZUCCO DI CRIMINALISSIMA BLOCKCHAINLABIT, DI CRIMINALISSIMA BHB - BLOCKCHAINLAB, DI CRIMINALISSIMA WMO https://www.facebook.com/giacomo.zucco - AL NOTO PEDOFILO NAZISTA, MAFOSO E KU KLUK KLANISTA ARNOLD CAZARES DI LAREDO TEXAS https://www.linkedin.com/in/arnoldcazares - AL FIGLIO DI PUTTANA STALKER VIA INTERNET, NONCHE' PURE NOTISSIMO PEDOFILO MEGA COCAINIMANE LUCA MORISI ( CHE AMA FARSI CHIAMARE ^ SATANAZISTISSIMENTE^ ... LA BESTIA, IN QUANTO FACEVA PARTE DELLE BESTIE DI SATANA, LE QUALI ERANO NOTORIAMENTE TUTT'UNO CON LEGA LADRONA https://danielesensi.blogspot.com/2010/01/la-disperazione-di-una-mamma-mio-figlio.html ED A CUI INFATTI FAREMO FARE UNA FINE "BESTIALISSIMA" https://www.welt.de/politik/ausland/plus180987808/Italien-Der-maechtige-Unbekannte-hinter-dem-Biest.html ) EFFETTUA MEGA TRUFFE, ORDINA OMICIDI, FINANZIA PEDOFILIA ON LINE, RICICLA SOLDI SUPER ASSASSINI A LUGANO!!! Appena abbiamo comprato Finter Bank Zurich dai massoni nazifascisti Pesenti, immediatamente abbiamo chiuso tutti i conti connessi, al, tanto quanto, massone nazifascista, nonche' famosissimo ladro, truffatore, azzera risparmi di ognuno che gli abbocca via iternet e non solo, nonche' criminalissimo pedofilo Paolo Barrai. Di delinquentissima Medicalchain, di delinquentissima Cryptolab S A, di delinquentissima Bigbit, di delinquentissima Bitcoin Cryptoeconomy, di delinquentissima Bitincubator & Venture, di delinquentissima Bgbit News Channel e delinquentissima @bigbitnewschannel. Attraverso i quali strumenti, lui ed il fallitissimo, idiota, davvero deficente, incapace, fallimentare trader Federico Izzi di Roma (che campa, di fatto, riciclando soldi mafiosi e facendo film pedopornofrafici, tanto e' vero che sta merda criminalissima di Federico Izzi di Roma, e' noto sulle rivere del Tevere, da chiunque, come "Er Zio Romolo incula bambini" e pure come "Er Zio Romolo della Camorra"). Sti due pezzi di merda criminalissimi spennano " i polli del web¨, vendendo loro abbonamenti annuali su criptovalute e non solo, totalmente fallimentari ( delinquentissimo servizio chiamato Bigbit) Costoro ti fan perdere tutti, tutti, e di nuovo tutti i risparmi ( posso mostrarvi centinaia di casi, venuti, disperati, a piangersene da me, a proposito). Insieme al figlio di puttana Natale Ferrara di Reggio Calabria, uno scarafaggio della Ndrangheta ( e di fallimentarissima e super stra ndranghetista Eidoo). https://valori.it/banche-politica-blogger-tutti-gli-affari-dietro-le-cripto-elvetiche/ Si, proprio cosi', insieme al figlio di puttana Natale Ferrara di Reggio Calabria o Natale Massimiliano Ferrara di Reggio Calabria, uno scarafaggio della Ndrangheta ( e di fallimentarissima Eidoo). Che e' passato da allevare pollame con la sua amatissima Ndrangheta a spennare penne ai " polli del web", che idiotissimamente cadono nelle sue trappole criminalissime ogni giorno. https://valori.it/chiasso-dove-riciclatori-ndrine-e-criptovalute-sincontrano/ Imboscatosi ora qui in Svizzera, per non finire in galera, ben appunto, a Reggio Calabria. Che ha rifilato a la merda di Ico completamente fallimentare chiamata Eidoo, crollata da 7 dollari a 0.60 dollari. Ora, l'altrettanto merdone nazista, razzista, ku kluk klanista, mafioso, ricicla soldi mafosi, pedofilo Donald Trump ( https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjfRrJT27WrzI1R9y5J8K9OQBk0n7ZUd4BeANpF9eU3gvNOgxBEmNc-J98E9FPg-woExFeJuwKMJx54ozD0oFpIiaDbneZTLZIDqDdZ30MZECl2rKBbCeCD0GAtlzFpRus-CwaR3mWEJws/s1600/trump+and+hooker.jpg https://whyweprotest.net/attachments/trump-pedophile-one-jpg.259858/ http://www.bubbleofdelusions.com/images/donald-trump-pedophile2.jpg https://www.newstalk.com/Donald-Trump-accused-of-statutory-rape-assault-and-battery-against-13yearold-girl https://www.noticiasaominuto.com/mundo/1045873/trump-tera-participado-em-festas-com-muita-cocaina-e-jovens-menores ) sta cercando, insieme al pezzo di merda nazistissimo ed assassino Jamie Dimon ( http://wallstreetonparade.com/2016/09/strange-deaths-of-jpmorgan-workers-continue/ ) di tirargli su detta merda! Il tutto, ovviamente, mentre lo stesso nazipedofilo merdone Donald Trump, tira su, come al solito, anche, i suoi tre grammi giornalieri di cocaina, presso la White "Powder" House! https://www.thedailybeast.com/the-drug-trafficker-donald-trump-risked-his-casino-empire-to-protect Torniamo in ogni caso, ora, al punto iniziale, jetzt, bitte. Appena noi di Bank Vontobel Zurich abbiamo comprato Finter Bank, abbiamo cacciato immediatamente il ladrone, truffatore, pure mandante di omicidi e notissimo pedofilo Paolo Barrai nato a Milano il 28.6.1965 ( o ladrone, truffatore, pure mandante di omicidi e notissimo pedofilo Paolo Pietro Barrai nato a Milano il 28.6.1965), dalla lista di nostri Banking Intermediaries. Fra i tantissimi crimini che lo stesso effettua, per noi banchieri svizzeri, il piu' in vista e' che lo stesso lava, lava, lava soldi assassini per la Mafia ( insieme al figlio di troia delinquentissimo Oliver Camponovo, noto fiduciario di ndrangheta, come pure insieme al pezzo di merda super stra ndranghetista Natale Ferrara di Eidoo )! https://valori.it/banche-politica-blogger-tutti-gli-affari-dietro-le-cripto-elvetiche/ https://valori.it/chiasso-dove-riciclatori-ndrine-e-criptovalute-sincontrano/ Come anche, lava soldi rubati o frutti di mega mazzette in connessione a Lega Ladrona ( famosi 49 milioni fregati allo stato di "Berlusconia" e non solo). Come dell'altrettanto pedofilo squarta magistrati Silvio Berlusconi ( il tutto insieme a quel criminale assoluto, truffatore, azzera risparmi altrui, ricicla proventi assassini e mega pedofilo Federico Izzi di Roma prima menzionato, noto, non per niente, in tutto il capoluogo laziale, sia come "Er Zio Romolo incula bambini, come anche " Er Zio Romolo della Camorra"). Niente merda nella nuova Finter Bank Zurich ( ora Vontobel Bank). Il puzzo della merda, scusate il temine, si attacca ai vestiti. Vadano costoro a riciclare i loro soldi mega omicida dal figlio di troiaccia criminalissimo Fabrizio Cieslakiewicz di Banca dello Stato Lugano, dal figlio di troiaccia criminalissimo Daniele Albisetti di Banca dello Stato Lugano, dal figlio di troiaccia criminalissimo Claudio Genasci di Banca dello Stato Lugano, dal figlio di troiaccia criminalissimo Patrick Lafranchi di Banca dello Stato Lugano, dal figlio di troiaccia criminalissimo Gabriele Zanzi di Banca dello Stato Lugano! Vielen Danke, Ya!!! https://grokbase.com/t/gg/cerberus-support-forum/15a1ybhrwm/chi-e-il-cesso-pedofilo-paolo-barrai-blog-merdato-libero-wmo-bsi-italia-srl-oltre-ad-esser-s https://www.mail-archive.com/python@py.cz/msg08252.html https://www.py.cz/pipermail/python/2018-February/013193.html ANDREAS NIGG. ORA VICE PRESIDENT AND HEAD OF ASSET MANAGEMENT. PRESSO SAFRA-SARASIN. ZURICH. LA SUISSE. SCHWEIZ. CH. EX VICE PRESIDENT BANK VONTOBEL ZURICH. https://citywire.ch/manager/andreas-nigg/d2395 https://www.bloomberg.com/research/stocks/private/person.asp?personId=30273980&privcapId=146032483 |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment