| |||||||||||||
Object-oriented design patterns in the kernel, part 1Object-oriented design patterns in the kernel, part 1Posted Jun 3, 2011 15:40 UTC (Fri) by daglwn (subscriber, #65432)In reply to: Object-oriented design patterns in the kernel, part 1 by chad.netzer Parent article: Object-oriented design patterns in the kernel, part 1
You're asking the wrong questions.
Which parts of C++? All of it! But people have to develop smartly, as with any language.
Specifying a language subset is a losing proposition because there will always be some feature outside of that subset that is the perfect fit for some need in the project. Artificially restricting developers is the wrong way to go. Code review, basic rules of thumb and other such things do a much better job of ensuring software quality.
As to the inheritance model, I have heard this claim many times and never once has anyone explained their objections. What is wrong with it? C++ inherited it from Simula, so your claim that nothing else uses it is incorrect.
(Log in to post comments)
Object-oriented design patterns in the kernel, part 1 Posted Jun 3, 2011 18:29 UTC (Fri) by chad.netzer (subscriber, #4257) [Link]
> You're asking the wrong questions.
Enlighten us as to the right questions.
> Which parts of C++? All of it!
On new projects, sure. C++ (imo) can be quite elegant when you code in the modern style, and not all the legacy predecessors (I started before mature templates, before exceptions, before the Standard Library, etc., and many codebases are still stuck in that age since compilers took *forever* to mature).
But that isn't what we are discussing. As I said, unless you plan to rewrite Linux from scratch in C++, any proposal on the table is about using a restricted set of features in some parts of the kernel.
> C++ inherited it from Simula, so your claim that nothing else uses it is incorrect.
My claim was that no one copied it from C++, so you're re-statement of what I said is wrong. And which languages copied C++'s design in this respect? What other language after C++ uses multiple inheritance, has virtual base classes, uses "protect" or equivalent, allows slicing, etc.? I'm happy to be enlightened if there is a language out there that said "C++ inheritance is spot on, let's copy it". Python, bizarrely enough, comes kinda close in some ways (to it's detriment).
Object-oriented design patterns in the kernel, part 1 Posted Jun 3, 2011 21:21 UTC (Fri) by daglwn (subscriber, #65432) [Link]
> Enlighten us as to the right questions.
Does this code or proposed design exhibit sound engineering given the project goals?
> As I said, unless you plan to rewrite Linux from scratch in C++, any
Why? There is nothing magical about the kernel. It's software. Even in a project transitioning from one implementation to another, there's no reason to artificial limit what people are allowed to do, especially _a_priori_.
> What other language after C++ uses multiple inheritance, has virtual
Ah, good, some concrete points.
Multiple inheritance is very useful. If a language with inheritance doesn't have it, it has a major missing feature.
Virtual base classes are trickier. They are painful, I admit, but necessary for some uses of MI. Many uses of MI don't need them at all. C++'s possible mistake was to place the decision point at the intermediate class level rather than at the "final" class level. But it's a convenience/efficiency tradeoff and I'm not totally sure the committee got it wrong..
By "protect" I assume you mean "protected." Protected methods certainly are useful. Protected inheritance, not so much but I'm sure someone has a use case for it.
Slicing is also a big pitfall. But I think it's a natural consequence of call-by-value semantics. One could argue that C++ should have made call-by-reference default but that would have broken C compatibility, a major strength of the language.
> I'm happy to be enlightened if there is a language out there that said
I don't think anyone has said that. I have not said that. To do so would be to say that the language is perfect, an impossibility in an imperfect world.
There are valid criticisms of C++. But to take that to an extreme and proclaim the C++ inheritance model "broken" or "wrong" is, well, wrong.
Object-oriented design patterns in the kernel, part 1 Posted Jun 3, 2011 22:26 UTC (Fri) by elanthis (guest, #6227) [Link]
> Multiple inheritance is very useful. If a language with inheritance doesn't have it, it has a major missing feature.
Sort of. Multiple inheritance in the C++ sense is useful simply because C++ doesn't differentiate between base classes, interfaces, and mixins. The need for multiple inheritance with multiple base classes is pretty small, and at least every example I've personally seen has been an example of bad interface design rather than a showcase for the need for MI (granted, my experience is not all-encompassing).
> Virtual base classes are trickier. They are painful, I admit, but necessary for some uses of MI. Many uses of MI don't need them at all. C++'s possible mistake was to place the decision point at the intermediate class level rather than at the "final" class level.
I will argue that if you start having intermediate classes very often at all, or a diamond tree, you're using inheritance wrong. Which most object-oriented developers do, unfortunately. A large part of this I fear is that it's simply taught wrong in schools. The classical examples of inheritance are things like Mammal->Dog, or Shape->Circle, or Vehicle->Car. These are attempts at modelling real-world "is-a" relationships inside of algorithmic data structures, which is really really wrong. It's a very long discussion to explain it in the necessary detail, and I believe Herb Sutter already did some fantastic talks on the topic (I'm having trouble Googling them though; maybe it wasn't Sutter that did them?).
Object-oriented design patterns in the kernel, part 1 Posted Jun 3, 2011 23:32 UTC (Fri) by daglwn (subscriber, #65432) [Link]
I think it's actually a strength that C++ doesn't differentiate among types of classes. It allows more flexibility and reuse. I agree with you that there should be a good case made before using MI.
How would, for example, making "mixin" a special kind of class look in the place of MI?
I'm not sure about "intermediate classes very often" part, but you certainly are correct about the diamond hierarchy. A diamond with state in the virtual base is usually poor design and causes countless headaches in constructors. A diamond without state in the virtual base (i.e. it's a pure interface) is sometimes useful.
isa inheritance is usually good design. hasa inheritance is usually bad design. For the latter, composition is almost always the way to go. If you can find examples where "isa" is the wrong thing to do, I am very interested. Myself, I tend to prefer generic code and composition to inheritance but there are obvious cases where inheritance is useful and necessary.
Object-oriented design patterns in the kernel, part 1 Posted Jun 4, 2011 0:50 UTC (Sat) by elanthis (guest, #6227) [Link]
> How would, for example, making "mixin" a special kind of class look in the place of MI?
The closest you get to what most people would consider a mixin in C++ would be the CRTP, but it's a little gimped because you can't properly specify that the "mixin" is implementing methods in an interface that the class inherits from.
e.g., if you have class Foo that implements interface IDoStuff, a mixin SimpleDoStuff might include members and methods that implement some or all of the methods of IDoStuff. There's no direct way to do that in C++, though, and so you end up with either grotesque inheritance trees or diamond inheritance.
The only way to handle common partial implementations of interfaces in C++ is to create intermediate classes, which then results in you having a ton of intermediate classes, and you start wanting to mix different sets of then, and then you end up with either (a) an uber base object replacing the interface, making all your object bloated and over-complex, (b) a metric crapload of intermediary classes with tons of code duplication, or (c) diamond hierarchies and virtual bases and all the problems those impose.
> isa inheritance is usually good design. hasa inheritance is usually bad design. For the latter, composition is almost always the way to go. If you can find examples where "isa" is the wrong thing to do, I am very interested. Myself, I tend to prefer generic code and composition to inheritance but there are obvious cases where inheritance is useful and necessary.
We perhaps are using slightly different definitions of "is-a", as I wasn't including interface derivation in that statement. Composition is the opposite of what I consider is-a. Yay for ambiguity in computer terminology. :)
(On a related note, composition is super important. Not understanding composition is the other thing that leads to massive inheritance trees and horribly screwed up architectures. Composition isn't necessarily trivial in C++ due to a lack of language/syntax support, but it's still possible to do and do well, unlike mixins which are borderline imposssible.)
Object-oriented design patterns in the kernel, part 1 Posted Jun 3, 2011 22:56 UTC (Fri) by chad.netzer (subscriber, #4257) [Link]
> Does this code or proposed design exhibit sound engineering given the project goals?
That is only the right question to ask in that it must always be asked, and is contentless. Clearly a good designer will start by saying, "What is a good, sound design for this task?" But knowing how to evaluate a design and implementation requires asking the kind of concrete questions that you claimed were not the right ones.
> Even in a project transitioning from one implementation to another, there's no reason to artificial limit what people are allowed to do, especially _a_priori_.
You started this whole thread by claiming "One does not have to use every feature of a language to get good productivity out of the language.", which implied a conservative approach to feature adoption. Now you are claiming that if Linux allowed for C++ development, that all features should be available for use without restriction. Change of heart?
> Ah, good, some concrete points.
You phrase that as though I haven't already been making concrete points. I disagree, and I think I've been more concrete in my points than you have. I find Linus's arguments about using C++ for kernel coding to be largely correct (for the Linux kernel), and your defense of your assertion that he is "dead wrong" to be unconvincing.
> But to take that to an extreme and proclaim the C++ inheritance model "broken" or "wrong"
Those quoted proclamations you are apparently attributing to me are also incorrect, btw.
Object-oriented design patterns in the kernel, part 1 Posted Jun 3, 2011 23:43 UTC (Fri) by daglwn (subscriber, #65432) [Link]
> But knowing how to evaluate a design and implementation requires asking
> the kind of concrete questions that you claimed were not the right ones.
Your overarching question was, "what parts of C++?" All of your other questions were about dealing with consequences of using a subset, save the one about overloading and that one is equivalent to, "how do we make sure we don't introduce bugs?"
This is how I look at things. Given a tool, use it. Everyone on the project should evaluate how that tool is being used. If we start with a tool, reduce its functionality by saying we can't do this or that with it, it doesn't eliminate the need to evaluate how we're using it, but it does eliminate the some possibilities of using it better when we find certain cases of poor usage.
> You started this whole thread by claiming "One does not have to use
Not at all. The two statements are entirely consistent. All the tools should be available and we should make sure we use them correctly. Of course a project in transition isn't going to use every language feature immediately, simply because not all of the code will transition immediately. That does not mean that this or that language feature should be off-limits when transitioning any particular piece of code.
> You phrase that as though I haven't already been making concrete points.
Forums are a poor way to convey expression. Believe me, no disrespect was intended. I was genuinely happy to see examples as I have been asking for them in various places for a long time.
> Those quoted proclamations you are apparently attributing to me are also
Perhaps I misunderstood the intent of your statement:
Btw, the inheritance model that you tout as a feature (for "simple
If so, I apologize. It reads to me like a condemnation of the entire C++ inheritance model.
Object-oriented design patterns in the kernel, part 1 Posted Jun 4, 2011 0:21 UTC (Sat) by chad.netzer (subscriber, #4257) [Link]
> This is how I look at things. Given a tool, use it.
I agree. Projects that adopt a tool like C++, should be prepared to adopt all of it. Those that don't want to adopt all of it, should seriously consider adopting none of it. The ones that want to adopt a subset of C++ (ie. "We'll just use it as a 'better' C, or 'C with classes'") should be prepared for the burden of that, and are probably best suited to a fairly small team of developer's (ie. not Linux sized). I think Linus was right to adopt none of it.
> The two statements are entirely consistent.
The statements themselves are not inconsistent with each other, but I feel the argument you are making with them is not, imo. But let's leave it. I think it is impractical for a large active codebase with wide collaboration to transition from C only, to fully incorporating and embracing modern C++, without a rewrite essentially from scratch. I'm not sure of any such examples in the open source world (though gcc was pointed out earlier as a related example), but perhaps I'm wrong.
> Perhaps I misunderstood the intent of your statement:
I think you were just restating my intent in your own words, but using the quotes made it appear that I said those words. I'd say 20+ years of C++ inheritance experience has shown it to be flawed: it's difficult for many to understand all the ramifications and options, carelessness leads to the fragile base class syndrome despite it's encapsulation features, people have devised the ugly "pimpl idiom" to deal with other compiler and encapsulation issues, it has multiple inheritance :), and so on and so on. I think C++ has been a useful experiment, and hopefully something better will now come to prevalence that has learned from it's flaws (disregarding Java et al; I mean a language w/ pointers).
Object-oriented design patterns in the kernel, part 1 Posted Jun 4, 2011 7:14 UTC (Sat) by chad.netzer (subscriber, #4257) [Link] > There is nothing magical about the kernel. It's software.This got me thinking about something else. There are about 5000 uses of kmalloc() in the linux kernel, but kmalloc() takes a flag argument. So, to replace these uses with idiomatic C++ would require widespread use of placement new(). However, using placement new requires care when deleting objects. So, rather than just using delete, you have to both manually call the class destructor, and then operator delete() with the right arguments to invoke the proper delete function (I suppose the kernel C++ stdlib could kludge the delete operator so that it works for placement new; now you are writing non-conformant C++) ie. struct T *p = kmalloc(sizeof(struct T), GFP_KERNEL | GFP_DMA); some_init_function(p); kfree(p);becomes something like: T *p = new (GFP_KERNEL | GFP_DMA) T; p->~T(); operator delete(p, GFP_KERNEL | GFP_DMA); // Or whatever it takes to match the call signatureThis unorthodox usage is necessary because the kernel is not just like other software. Not when it comes to things like memory allocation. And what about a std::vector of struct *T? How do you allocate those objects with the right memory flags? Perhaps there is an elegant solution to this, most likely by eschewing bare pointers in the kernel and always using some templated smart pointer class. A fairly radical change for kernel development. What are your thoughts on it?
Object-oriented design patterns in the kernel, part 1 Posted Jun 4, 2011 7:19 UTC (Sat) by elanthis (guest, #6227) [Link]
I feel your argument is a little weak.
Video games are almost certainly "just another piece of software" and we deal with the exact same memory management types of issues. Many game engines outright ban the use of new and delete because of the problems they cause, requiring instead that specialized factories and memory managers be used, especially on console titles and mobile games. It's every last bit as complex of a set of interfaces as the kernel, if not more so. And they're still just software, and they still mostly all use C++. :)
Object-oriented design patterns in the kernel, part 1 Posted Jun 4, 2011 7:36 UTC (Sat) by chad.netzer (subscriber, #4257) [Link]
Whereas the existing kmalloc/kfree idiom is quite straightforward. So where is the gain? If the most basic memory allocation features of the language have to be banned from use, it's hardly a sales point for adopting the language. You use it *in spite* of these deficiencies, just as Linux does with C.
Object-oriented design patterns in the kernel, part 1 Posted Jun 5, 2011 19:32 UTC (Sun) by elanthis (guest, #6227) [Link]
C++ has problems. The thing is, no other language is better. Sure, C is clearer about memory allocation. But it lacks critical things like templates. Which also have problems, but without them it's literally impossible to write a sane container library, generic algorithm library, or even a simple sort that doesn't end up making logN function calls. Dynamic languages or languages like C#/Java almost manage this, but either screw up safety or just totally screw up performance and memory usage in their generics implementation.
And then there's user-defined value types. Trying to do basic graphics work in any language other than C/C++ is a nightmare, because your vectors are referece types. In games, I use vec3's and vec4's more often than I use int's and float's. Now imagine if every number in your language of choice was a reference type. That's what doing games (or just about any other interesting mathematical application) in every single popular language besides C/C++ is like. C's failing here is the lack of operator overloading for user-defined types, which just makes doing simple expressions with vec's and such a total pain. Even languages supposedly focused towards games or systems programming, like C#, utterly fail when it comes to user defined types.
And then in the C/C++ realm, C++ actually solves the very memory management problems we started talking about through it's ability to let users define their own handle types. Raw pointers in C++ present a lot of problems that also exist in C, but C lacks the ability to solve those problems at a language/API level like you can in C++.
So yeah, C++ fails in many ways, and fails hard. Every other language just fails even harder (for certain classes of application, that is). D comes closest to being a viable replacement, but it's not better enough to justify breaking compatibility with all the excellent C++ libraries out there.
Object-oriented design patterns in the kernel, part 1 Posted Jun 6, 2011 19:17 UTC (Mon) by cmccabe (guest, #60281) [Link]
In my opinion, video games are a great example of a place where you *should* use C++. Kernels and systems-level software are a great example of a place where you should *never* use C++.
Why do I say this? Well, C++ was designed to increase the speed of development and allow you to mix high-level and low-level code easily. It is very good at doing those things. At the same time, a clever programmer can get reasonable performance out of C++ by spending a little time optimizing.
When writing a video game, you don't care that much about long-term maintainability or safety. An exciting game that crashes a few times a month will sell many more copies than a boring game which is rock-solid. Stuff gets rewritten from scratch every few years to take advantage of the latest and greatest hardware. If things are not written in the absolute most efficient way, who cares? You just keep tweaking things until the game runs all right on the target hardware.
Kernels are the opposite. There are still pieces of code in the Linux kernel that go back to the early 1990s. Maintainability and stability are much more important than features or speed of development. It's important to use a simple style, in a simple programming language, that many different contributors can understand and use. Efficiency is key-- we don't have extra cycles to burn on things like std::string or std::map. In some structures, people are reluctant to enlarge the structure even by 4 bytes for performance reasons.
A lot of people claim that C++ is somehow safer than C. But this is ridiculous. C++ has all of the different flavors of undefined behavior that C does, plus many, many more. C++ has a lot of "generated code"-- default copy constructors, default destructors, and so on, that will burn you if you're not careful. Again, it's about speed of development, *not* safety.
Claiming that C++ is faster than C, or even as fast, is equally ridiculous. Even the most basic operations in C++, like iostreams, are much slower than the C equivalents like printf. Maybe some kind of theoretical perfect programmer could write equally fast, or even faster, code in C++ than C. But in the real world, programmers will take shortcuts if they exist. Let me draw an analogy-- if your wife bakes a cheesecake for you every night, you're going to get fat. Yes, in theory you could not eat the cheesecake, but it's right there.
So we're left with the real C++ advantage-- speed of development. I want to be fair here. C++ is good at doing what it does. But let's not get confused here-- it's not the right choice for a lot of projects. Use the right tool for the job.
Object-oriented design patterns in the kernel, part 1 Posted Jun 7, 2011 3:40 UTC (Tue) by elanthis (guest, #6227) [Link]
You're making a few claims I have to disagree strongly with, but in few words as ive got to walk out the door in a few. First, I don't think you are quite in tune with game development, at least not professional game development. Stability and even security are quite important - nobody wants to be Fallout New Vegas. Second, game engines are not rewritten that often. All of the popular engines are well over a decade old, and the majority of the code has not changed in architecture at all. Most crashes you see in games are actually video driver crashes, save a few particularly poorly engineered titles.
C++ is very much a safer language. You bring up hidden code and such as if that makes it unsafe, which is silly. C++ doesnt just magically do things wrong behind your back anymore than C does. Yes, a destructor runs "automatically" but never ever unexpectedly. On the other hand, C requires programmers to cut-n-paste large swaths of boilerplate code, leading to a much higher bug count in general.
Simple fact is that there are kernels written in C++ which work very very well.
Object-oriented design patterns in the kernel, part 1 Posted Jun 7, 2011 6:13 UTC (Tue) by cmccabe (guest, #60281) [Link]
> First, I don't think you are quite in tune with game development, at least
> not professional game development. Stability and even security are quite > important - nobody wants to be Fallout New Vegas
Look, I'm not trying to trash game development or game developers. I know you guys have a difficult and challenging job.
But let's be realistic. If I'm the project manager and I have a choice of releasing with a crashing bug or two or releasing a game that is dull or outdated, I am going to release with the bugs. If I don't, I'm going to get fired. Nobody wants a game that looks like it should have come out last year.
On the other hand, the economics are different for some other kinds of software.
> C++ is very much a safer language. You bring up hidden code and
It's not silly at all. Every time I write class with any kind of non-trivial destructor, I have to remember to hide the copy constructor and assignment operator. If I fail to do this, a simple typo later in the program-- say typing use_foo(Foo f) instead of use_foo(Foo &f)-- could bring the program to its knees.
Or take conversion constructors or default parameters. Here's a true story of something that happened very recently. Someone on our project decided to change a function prototype from foo(int i) to foo(const MyObject &o). What he didn't realize was that there was a conversion constructor from an int to a MyObject. So when he overlooked this little gem:
The compiler happily generated this:
Needless to say, the results were not what he intended at all.
Implicitly generated code hurts. Default constructors hurt. Default parameters hurt even more. You might disagree, but I've had a lot of time to come to this opinion.
> Simple fact is that there are kernels written in C++ which work very very
Well, as I already mentioned, there is XNU, which has no templates, no RTTI, and no exceptions, but is "technically C++". Apparently the Windows NT kernel also has some kind of C++ support-- again, I think exceptions are left out, as well as who knows what else.
I would say a bigger C++ success story is the success of the LLVM project. They managed to write a very capable compiler in C++, which has been gaining a lot of momentum. One of my friends who works on the project is also one of the few people who can stump me with a C++ question. I guess it's hard to out language-lawyer the language implementers!
But oh, they don't use exceptions :) And the LLVM library is 20MB when compiled, whereas /usr/bin/gcc is 262kb.
C++ has been the inspiration for a lot of other languages like Java and Golang, and I respect it for that. It got a lot of things right, and it's still the language that I know the best. But can't we have some new ideas after all these years?
Object-oriented design patterns in the kernel, part 1 Posted Jun 7, 2011 6:24 UTC (Tue) by elanthis (guest, #6227) [Link]
Sure, there's cases where C++ bites you. There are cases where C does this, too, and there are many ways in which C++ helps you.
I doubt I'll convince you to change your opinion with anything short of a small novel, though. :)
Object-oriented design patterns in the kernel, part 1 Posted Jun 7, 2011 7:46 UTC (Tue) by jezuch (subscriber, #52988) [Link]
> And the LLVM library is 20MB when compiled, whereas /usr/bin/gcc is 262kb
Are you sure you're not looking at just the GCC driver that invokes the actual compiler?
jezuch@zx-spectrum-1:~$ du -shc /usr/lib/gcc/x86_64-linux-gnu/4.6/{cc1,cc1plus,lto1}
Object-oriented design patterns in the kernel, part 1 Posted Jun 7, 2011 18:54 UTC (Tue) by cmccabe (guest, #60281) [Link]
I stand corrected. I thought that binary was way too small... but ldd didn't tell me anything useful.
It's been a long time since I built gcc. Even back when I did embedded stuff, we always seemed to use prebuilt toolchains.
Object-oriented design patterns in the kernel, part 1 Posted Jun 9, 2011 14:21 UTC (Thu) by renox (subscriber, #23785) [Link]
> Implicitly generated code hurts. Default constructors hurt. Default parameters hurt even more. You might disagree, but I've had a lot of time to come to this opinion.
Sorry but C++ poor mix of features doesn't mean that those features are always bad..
Object-oriented design patterns in the kernel, part 1 Posted Jun 9, 2011 16:56 UTC (Thu) by jd (guest, #26381) [Link]
Well, no. Implicit code is (IMHO) always a Bad Thing because when the specs or compiler change, the resultant binaries will change behaviour when given the same source.
The source is a specification document, to all practical intents and purposes, which the compiler uses to generate a program. If the program can change in nature for the same specification, the specification is incomplete and insufficient.
In other words, by depending on something external (in this case, the compiler) you cannot do reliable testing. There are too many external parameters that you can never reliably take account of. Good engineering practice is to always work to reduce or eliminate the unknowables. If the compiler is any good, it'll ignore initializing to the compiler's defaults since the instructions generated by the compiler's default will already be present. If the compiler isn't any good, you really shouldn't be trusting it to be doing the Right Thing anyway.
If you explicitly initialize, you always know the state of a variable, no matter what new C or C++ standard is produced. This is guaranteed safe.
Compiler-tolerant software is necessarily well-engineered software. Yes, it's more work, but if you wanted to avoid work, you'd not be using C or C++, you'd be using a fourth- or fifth-generation language instead. The only reason to use anything in the C family is to be able to balance development efficiency with code efficiency. Higher levels of language offer better development efficiency, lower levels (Fortran, assembly, etc) offer better code efficiency. Neither is useful on its own for something like an OS kernel, which is why nobody writes general-purpose kernels on the scale of Linux in either Erlang or IA64 assembly.
(Kernels do exist in both those, and indeed in Occam, but because of tradeoffs are almost always much more special-purpose.)
Object-oriented design patterns in the kernel, part 1 Posted Jun 13, 2011 0:20 UTC (Mon) by cmccabe (guest, #60281) [Link]
> Plus C's lack of initialisation also hurt a lot, no?
I remember a thread here on LWN a while back where people were complaining about a performance regression in the kernel caused by zeroing struct page. So it seems that at least in some corner cases, not initializing memory is a feature. In a perfect world, non-initialization probably should be something that the programmer has to ask for specifically, rather than the default. But C was designed in the 1970s-- give it a break already.
When C++ was designed, in the mid-1980s, the decision was made to keep all the old uninitialized variable behavior and add some more. So if you create a C++ class with some primitives, and forget to initialize them in one of the constructors, they'll be uninitialized. This also applies to copy constructors. The rationale was that programmers shouldn't have to pay for what they didn't use.
Luckily there is some relief in sight, in the shape of Coverity and similar static analysis tools. These can catch most uninitialized variables.
|
|||||||||||||