Interview with Bjarne Stroustrup Dr. Carlo PescioInterview with Bjarne StroustrupThis is the original English text of an interview with Bjarne Stroustrup,later translated in Italian and published in Computer Programming No 50,September 1996. Follow this link for the translatedversion. In the following text, CP stands for Carlo Pescio and BS forBjarne Stroustrup. CP: Are you satisfied by the results and pace of the C++ standardizationeffort? I mean, on the one hand, it is a proof of the success of the language,but on the other hand it is adding a lot of bureaucracy; do you miss theinitial freedom you had on core language issues? BS: Naturally, my patience has been sorely tested but by andlarge, I'm happy with the outcome of the C++ standardization effort. Withone minor exceptions, ISO will have the features I feel it really needsand none that I find harmful. ISO C++ is a much more powerful and coherentlanguage than the early versions of C++ was - and no major features wasadded that I didn't work on and approve of. Some details of ISO C++ mayshow signs of "design by committee," but the overall set of facilitiesis a better match for my original view of what C++ should be than earlierversions of the language. The primary reason I took part of the standards effort was that thecommittee was convened before I had been able to complete the language.C++ without templates and exceptions would have been unacceptable, andC++ without namespaces and run-time type information would have left usmuch poorer than we are today. It is easy to exaggerate my "initial freedom." I decided earlyon that I wanted my language to be compatible with C and that I wantedto support real users. This placed constraints on what I could do. I thinkthe alternative would have been to design yet another cult language. Ican't wait for the standard to become complete. The C++ community needsa solid standard and I need the time I have had to devote to the standardseffort over the last six years or so. I think the language has benefittedsignificantly from my efforts in the standards committee. I was the chairof the extensions sub-committee that processed all requests for extensionsand other major changes to the language and was generally involved in mostmajor issues - including the design of the standard library. Standardizationis necessary for a language with C++'s number of users. However, I wouldn'tcall standardization fun. Much credit - much more credit than is usuallyaccorded to "faceless committees" - should go to the dozens ofpeople who volunteered their time and very considerable efforts to thestandard year in and year out. I documented many of their names and effortsin my recent book "The Design and Evolution of C++" (usuallycalled D&E). CP: Lot of readers would like to know if there is a "thec++ language - 3rd edition" and/or a 2nd edition of theARM under way... BS: I'm working on a 3rd edition and thinking of something toreplace the ARM. However, I don't see a point in writing a new book unlessI have a lot of new things to say, so progress is slow. My aim is to makethe 3rd edition as much an improvement over my 2nd as the 2nd is over the1st. In other words, I want to produce something even more approachablethat the 2nd yet containing information that will be new and exhiting toessentially every C++ programmer. I cannot predict when I complete, butnoone who needs a good textbook should wait for the 3rd edition. The 2ndedition is still one of the most complete, thorough, and up-to-date textbooksavailable. Naturally, I cannot publish an ARM replacement until there isa standard to annotate. Until I get those books written, D&E is thebest source for information about new features in particular and the reasonsbehind the design of C++ in general.CP: Are there any technical decisions that in retrospectiveyou'd like to change in C++ - not something you had no way to get accepted,but something that further experience proved to be somehow flawed, andthat you'd like to change if you had the opportunity to (even if todayis not possible for compatibility reasons). BS: There are lots of details, I'd like to tinker with, but thereare no major features I would like to delete (even if I could) or majorfeatures that I both like and know how to add. When people ask this kindof question, they usual have some feature such as MI or RTTI in mind, solet me say that C++ without one of those would be a poorer language. Iuse both extensively and the workarounds I would have to use if they weren'tthere are not pretty sights. There are of course examples and explanationsin D&E.CP: Actually I mostly had [changes to] virtual functions inmind: for instance, I'm not very fond on the fact that a virtual functioncan be redefined in a *privately* derived class. The function is not accessible- yet is redefinable; this conjure a bit on the usefulness and safety ofprivate inheritance. To a larger extent, you probably remember Sakkinen's papers on the "inheritanceprinciples of C++": he made some fine points, and I particularly likedthe fact that [under more restrictive rules] one would not have to extendthe liability of invoking the constructor of a virtual base class fartherthan "necessary" in the inheritance graph. In fact, while I understandthe reasons behind the current rules for VBC in C++, I have to admit thatin some sense, invoking the constructor of a VBC weakens the encapsulationprovided by intermediate classes. On the other hand, we know the strongand weak points of C++ through years of use - and probably Sakkinen's proposalswould have lead just to other weak points, although I sort of like themas far as "programming style" is concerned. BS: Fundamentally, I consider these these issues purely academicand of no interest to practical programming. It is possibly to design aconstructor to maliciously access information, but a constructor writtento initialize its own data is fundamentally harmless. Furthermore, if thevirtual base class is public - as I always recommend - all classes aresupposed to know it exists and should expect its constructor to be invoked.In this, virtual base classes doesn't differ from other bases. If the virtualbase is declared private somewhere and public elsewhere and if the mostderived class initializes it in a way that surprises the writer of theprivate virtual base, I guess "the encapsulation provided by intermediateclasses" has been weakened. However, if that is someone's worst problemthat someone must be truly blessed. I see no problem with overriding a virtual function by a private functionor from a base in which the base is private. If you consider a base classan interface, it is of no concern of the users of that interface how itsimplementors (the derived classes) provide their implementations. I findit easy to imagine a derived class that makes its overriding functionsprivate exactly to prevent use of the derived class except through theintented base class interface and to inhibit further derivation. If a baseis private, it may still be accessible to friends, or the derived classmay be handing out pointers to its (private) base on request. For example,a derived class could return its base class interface as the result ofan operation that performed system-level acccess control checks. class A { virtual void f() ; } ;class B : private A { void f(); // implementation A* get_A(Rights& r) { /* check rights */ return (*A)this; } } ;CP: On the other hand, private inheritance is not transitive,so in a case like: class A { virtual void f() ; } ; class B : private A { void h() { f() ; } } ; class C : public B { virtual void f() ; } class A is not an interface for class C, A :: f() is not accessiblein C, but is redefinable in class C. We could just say that the culpritis class C implementor, who based his code on an implementation detailof class B (the fact that class B is-implemented-using class A). Some maylike to have that forbidden from the language... BS: Yes, that's a messy example. However, it is not easy to crafta set of rules that outlaws every messy example without also doing damageby outlawing examples that some consider messy, yet others deem essentialfor their work. In general, I'm against restrictions for which I don'tsee a practical purpose. I do not consider orthogonality a primary designaim, but certainly I prefer it whenever there are no first-order reasonsfor non-ortogonality. The C++ access rules are very orthogonal (with namingrules, overriding rules, etc.) and I see no strong reason for them notto be. People can be surprised by the rules, but so they could by lessorthogonal rules. CP: I understand your opinion and I agree to a large extent.That's why I said this kind of "rule" may be good as far as "programmingstyle" is concerned. There are certainly times when something likethat may be useful (for instance in reusing a library without source code)and in that case one may "violate the rule" and do it, becauseC++ is not a motherly, restrictive language. BS: I would have liked C++ to be more capable of catching logicalerrors made by programmers. After all, many of the C++ features has exactlythat effect when compared to what you'd have to write in C to perform anequivalent action. However, I do not think that safety should be boughtat the cost of complicating the expression of good solutions to real-lifeproblems. This - and compatibility concerns - limits what can be done tomake the language itself cleaner. I recommend the use libraries to makeuse of C++ safer for specific applications. For example, if someone worryabout the fact that C arrays aren't range checked, they should use a range-checkedvector class. I do that most of the time myself, especially for debugging.CP: Let's go back to the retrospective on C++... BS: For good and bad, I have maintained a high degrees of C compatibilitysince the earliest days of C++ and the standards committee has followedmy ``as close to C as possible - but no closer'' policy. Many things inC++ could be better from a language-technical point of view, but that isnot realistic. When I started I decided on compatibility and tried thebest I could to live with second-order flaws, fixing only problems relatingto the type system. The alternative would have been to build a yet anothercult language: Beautiful in the eyes of its adherents and eliciting nothingmore than ayawn from almost all who program to get results. Had C not beenthere to be compatible with, I would have chosen some other language elseto be compatible with. I was - and am - convinced that my time would nothave been well spent inventing yet another way of writing a loop. Concurrency is an issue that keeps coming up. Most people like someform of concurrency and would like to see it directly supported in C++.However, there is no one form of concurrency that serves more than a smallfraction of the C++ programmers who need concurrency really well. OS writersneeds one form of concurrency, database users another, and network applicationimplementers yet another. Thus, I decided not to include specific featuressupporting concurrency in C++. People who wants some form of concurrencycan - and does - support it through language extensions of (preferably)libraries. The standard committee backed me on that issue also; we knewmany attractive concurrency schemens, but not one that could serve a largemajority of C++ users. The range of areas where C++ is used it truly amazing.I was asked to write an article on C++ for ACM's second conference onthe history of programming languages (they have one every 15 years!). Forthat paper, I was asked what I considered my greatest mistake with C++.In my mind there was just one candidate for the title of "worst mistake:"I failed to produce an acceptable foundation library and ship it with release1.0 in 1985. My excuse was that I didn't know how to write a good enoughlibrary and that I needed templates to provide efficient, flexible, andtype-safe containers. The result of that mistake is the current mess ofof incompatible foundation libraries of widely differing philosophies andqualities. Fortunately, the standards committee was able to agree on an excellentstandard library. We now have what I failed to produce and something thatI did not know how to design and implement ten years ago. The frameworkof containers and fundamental algorithms that is a major part of the standardlibrary was primarily the work of Alex Stepanov. It actually has some rootsin our search for principles and techniques for good library componentsback in the years before and after release 1.0, so the delay wasn't completelywasted. CP: As you know there are proposals to add some of the C++ featuresto C9x, for instance a limited support for classes. I had the impressionof a naive approach, e.g. they don't have constructors, assignment overloading,and so on. What's your position on the "new ANSI C"? BS: The features did look naive from my perspective and the explanationsthat acompanied them seems to reflect a lack of appreciation of how C++was evolved in response to feedback. I had (and still have) an overallview of what the language is supposed to do, but within that overall view,I was careful to seek feedback on the language as it evolved to adjustits features to real experience and needs. Attempting to pick a small subset of features from C++ to provide "amuch simpler language with almost all of the power of C++" is in myopinion doomed to failure. Unless very carefully chosen based on real experience,the features will only partially support coherent programming styles andone feature will lead to another - only when guided by an overall viewof what design and programming styles are to be directly supported willthe additions lead to a coherent language. It would not be reasonable for me to try to tell the C community howthey should standardize their language. If I did, my advice would probablynot be wellcome anyway because the people who would value my advice mostwould be programming in C++ anyway. The C committee will do what it wantsto with C and presumably they know best for their core community. any extensionsas compatible with C++ as at all possible. The programming community doesn'tneed yet another incompatible C dialect. K&R C isn't dead yet, currentANSI C will persist long after an new standard is promulgated, and variousvintages of C++ will also exists well after the C++ standard becomes official.Things always takes longer than we think and that we would like. New featuresin C9x will necessarily become an extra source of instability in the Cand C++ community. CP: Talking of C++'s sons, I cannot avoid to mention Java...how big in your opinion is the bandwagon effect, and were (if anywhere)you see Java's real strengths. I know that as a language designer, youare very careful on criticizing languages - sort of "any languagehas a niche" - but what are your gut feelings? BS: Java has a C++-like syntax, but is a fundamentally differentlanguage supporting a different culture and a different (rather narrow)range of programming styles. Java certainly isn't the C++-like languageI would have designed in the absence of compatibility constraints. CurrentlyJava rides amazingly high on expectation, Sun marketing money, and itsintegration with the Web. Time will tell how it will fare as a general-purposelanguage, and how the majority of programmers and managers will react whenthey discover that the "security" of Java and in particular ofJavascript leaves much to be desired. People confuse programming languagetype safety (which a correct Java implementation provides) with security;that is, the preservation of system integrity and privacy (which can beseriously compromised using Java). Our security people jokingly refersto Java as "the virus implementation language" and strongly recommendthat we run with Java and Javascript disabled in our netbrowsers. Backto programming language issues: C++ - is a better C - supports data abstraction - supports object-oriented programming - supports generic programming Of these, Java covers the object-oriented part only, and it does soin ways that differ significantly from C++. CP: Some of the newest C++ additions have been useful but smalldetails - explicit, mutable - or "escape from C" features likethe new-style casts. Do you see any future for more design-oriented featuresin the language? For instance, maybe there are some valuable inspirationsin projects like Annotated C++ or Larch-C++, leaning more toward specificationsand less at the coding level, or some ways to add some more semantics -for instance make object-sharing decisions more explicit. Or is your intentionto strengthen the language were is already strong - in the embedded / systemprogramming / performance-critical areas? BS: C++ is part of a general drift towards a more declarativestyles of programming. However, as far at the official definition of thelanguage is concerned changes to the language and standard libray now hasto stop to give implementers, users, tool builders, teachers, etc. a chanceto catch up. Naturally, experimentation will continue (though most likelynot by me), but in my opinion the C++ developer community needs stabilitymore than anything else. C++ is now complete and coherent at what it does;further work will have to stay in sub-communities (such as academia) fora few years now. I think most people yet have to appreciate the strenghts of the templatemechanism for various forms of specification. For example, here is theoutline of how one can define a list so that a single implementation isshared by all lists of pointers: // general list<T>: template<class T> class list { /* ... */ }; // specialization for lists of void*: template<> class list<void*> { /* ... */ }; // general list of pointers (implemented using list<void*>):template<class T> class list<T*> : list<void*>{ /* ... */ }; The specialization mechanism used here allows different implemetationsto be chosen (using type deduction) while still providing the user witha single general interface. One important aspect of this is that it strengthensthe declarative nature of C++ programming while simplifying the user'sinterface and improving run-time efficency. Such techniques in the standardlibrary allows us to provide a single general sort() routine that for realexamples have outperformed to C standard library qsort() by a factor ofseven! CP: In IEEE Computer, February 95, Prof. Wirth labeled C++ as"a language that discourages structured thinking and disciplined programmingconstruction". I cannot say I agree, or that I find Oberon encouragingmore structure and discipline than C++, but is there anything you'd liketo concede to the purists/academics out there, that have to decide betweenteaching C++ because is useful in real world, and not teaching it becauseit is too distant from the formal, specification-based approach often usedin CS teaching... so they end up teaching Eiffel because of all the "programmingby contract" promotion or Smalltalk because "is pure OO"...BS: Professor Wirth isn't known for being generous with praisefor languages he hasn't designed himself, so I cannot say I'm surprisedby his eveluation. On the other hand, I think he is flat wrong. C++ isa more-than-adequate tool for good design, for industrial scale programming,and for precise thinking about serious problems. I guess this would bea good place to express my gratitude to the designers of Simula and C forproviding a solid base for me to build C++ on and for being such genuinenice people. I also learned a fair bit from many other languages. If youknow where to look, you can find traces of Algol68, ML, Ada, and BCPL inC++. There are a lot of great languages around. Everyone should aim atbeing proficient in more than one language - that holds for both programminglanguages and natural languages. Another language adds significantly toone's world view and abilities. There are lots that could be better inC++. However, that is true for every language in real use. Even those thatclaim to be "pure." In my experience the problems with C++ arenot serious for teaching nor for real use. Naturally, a student can failto learn and a teacher can take an approach that makes learning unnecessarilypainful. However that can and does happen in every language. C++ has theadvantage that its use scales to real world problems in many diverse applicationareas. Much of the ease of learning cleaner/newer languages comes by simplificationsthat force its users to abandon the language when they hit an applicationoutside the domain where the "clean" language is a reasonablechoice. Naturally, this can happen to C++ users also, but only rarely inany field that somehow touches upon systems programming. C++ has cleansubsets and the complexity comes when people starts playing with featuresand programming styles (``paradigms'') that require more extensive understanding.This is where users of "cleaner" languages often has to resortto alternative, lower-level, and "unclean" languages - usuallyC or C++. In my opinion, C++ should be taught in stages and with a strongemphasis on concepts. CP: Good point, really. Still, one might imagine an even cleanersubset, for instance a "student-C++" where an array is not castto a pointer without the user asking for that, and some more limiting factorson the same spirit. Do you think it could be a useful teaching tool (andperhaps a production tool for peoples less bound by C compatibility), orjust a source of confusion? BS: Actually, I'd like to see a ``student C++'' where built-inarrays wasn't used at all. Instead students would use vector, list, andstring classes from a teacher-provided library (based on the standard libraryno doubt). That is easily done and easily enforced in a teaching situation- even without compiler changes (just decrease the grade given in a built-inarray was used). Similarly, a teacher would find it easy to ban explicitcasts; they have no place in the kind of code a beginning student shouldbe writing. The difficult part of learning C++ - or any other language- is learning the new programming and design techniques, not the languagefeatures used to express them. Far too often, people gets obsessed by language features. Far too often,programmers get lost in a futile attempt to understand every aspect ofa rich language without sufficient background to understand the techniquesthe features exist to support. It is worth noting that even C++ is ordersof magnitudes simpler than the environments, frameworks, and major applicationswe work with in real-world application development. In teaching, C++ has been hurt by its close - and valuable - relationshipwith C. Because C++ is (almost) a superset of C, many think that they mustlearn (almost) all C features and techniques before approaching C++. Thisis not so, C++ is in many ways better behaved than C, and libraries canbe used to avoid having the student face the complexities of C pointermanipulation, casting, arrays, etc. until the basics have been learnedin an environment containing proper vectors, strings, etc. C++ can be -and occationally is - an excellent language for teaching programming, programmingstyles, design, etc. However, we must distinguish the teaching of programmingfrom the teaching of programming languages. That done, we might make someprogress and might even avoid many of the silly language wars that toooften wastes our time. One strength of C++ as a teaching language is that it lends itself tothe teaching of a variety of design and programming techniques. The alternativeis to teach a variety of "cleaner" languages to illustrate thesame range of techniques. What I consider flat wrong is the present onedesign and programming style - usually embodied in a single programminglanguage - as the one and only true style. A professional programmer orcomputer scientist should eventually be comfortable with C++, Smalltalk,ML, Lisp, and Eiffel - just to mention a few. Naturally, few people canbe real experts in more than one or two or those at one time, but the idealmust be to be acquainted with all and over time try out every one in somereal project. CP: C++ exceptions have been criticized as hard to use correctly- cfr the Cargill's article in C++ Report, the "need" to introduceauto_ptr in the standard library to make pointers more manageable underthe presence of exceptions, the mismatch between templates and exceptionspecifications. It also seems to be somehow difficult to implement: Borlandhad serious problems linking together DLLs with and without exception handling.Not to mention the "retry" debate, that you covered well in yourD&E. So, considering that exception will also make the learning curvefor C++ steeper, do you think that - as they are in C++ - exceptions arepaying off? BS: Every new feature is deemed hard to use, expensive, and unnecessaryby some when it first appears. Of the many "problems" pointedout, few are real problems in real programs. I find that exceptions significantlysimplify my code. Like all really worthwhile features, they require somenew thinking and some new ways of organizing code (if not, how could thefeature be a significant improvement?), but I think that they are emminentlyworthwhile. I consider the so-called "mismatch between exceptionsand templates" bogus. Exceptions are for building firewalls againsterror conditions. That is, you choose a specific interface and decide tolet only a subset of error conditions through. Almost all templates arepoor candidates for firewalls. Templates are deliberately designed to interactvery closely with user-defined types and if you have any sense you'd nottry to build a firewall right through closely interwoven code. If that'sa mismatch, so be it. However, I see it simply as independence of the concepts.They do differnt things and they can be used in combination. CP: to some extent, there is a mismatch between templates and*exception specification*; since templates uses the actual arguments insome way, it is almost impossible to end up with a correct specification,even on innocent-looking, simple code (e.g. a template function for comparison)...I'd say in general that if there is any dark side in exceptions, is thatthey makes innocent-looking code not so innocent anymore. BS: Actually, a lot of such "innocent looking code"was never so innocent. Such simple code is often full of unchecked errorconditions and subject to being bypassed by C-style setjmp/longjmp. Thus,exceptions focus attention on a problem that many prefer to ignore, butthe complexity is there already; it is not introduced by exception handling.I don't think it makes sense to add exception specifications to templatefunctions - at least only to rather unusual template functions. The reasonis - as you correctly point out - that the exceptions potentially thrownare the ones thrown by the template plus the ones thrown by the templatearguments. That is one reason that I say that templates are usually notgood candidates for firewalls. I do not believe that it makes sense tomake every little piece of code bulletproof. Instead, I prefer to expresssystems in terms of sub-systems and make the sub-system boundaries thefirewalls. That is where I use exception specifications. CP: An area where C++ seems still weak is object persistency...there are a number of libraries/tools, but in most cases you end up needinga custom preprocessor or some handcoded function. RTTI seems a promisingway to go, but unless there is some standard, it would be just anothernonportable extension... BS: I'm not at all sure that persistence belongs in a general-purposeprogramming language. Different people need different types of persistentdata with radically different requirements on performance, reliability,access control, nature of quiries, etc. I think it is right to leave thisissue to library vendors and database vendors. I prefer to limit the useof preprocessors and extra-linguistic tools, but sometime they are needed.In my opinion, a programming language should not try to do everything.It cannot do everything well anyway. And yes, RTTI can be of considerablehelp to implementors of various persistence and data base services. CP: You are the designer of one of the most successful languagesever - do you have any suggestions to the countless peoples in academywho crunch out yet-another-language every other day? BS: Be guided by problems. A useful language is a solution toa well-understood set of problems rather than simply something that fullfilsall the currently fashionable criteria for what a programming languageshould look like. If you don't have a serious problem that cannot be handledreasonably with any existing language, don't even think of designing yetanother language. Language design is a field with an almost 100% failurerate. No sensible person would enter that field if there was an alternative.So, look for serious programming problems without acceptable solutions,and try hard not to get involved in language design. If you must designa new language, borrow as much as you can - with acknowledgements - froman existing language. Be prepared for failure, and for extraordinary amountsof work should you beat the odds and succeed. CP: The other most successful language is visual basic. Somesaid that it delivers where OOP/C++ promises, that is, lot of pluggablecomponents, true reuse, maybe at the expense of some underengineering.Do you feel it right that interoperability between different C++ compilersis left to third-party products like SOM, and is not part of the standard?Of course any binary standard would limit the freedom of the compilerswriters, but that's true for *any* standardized issue. One may squeezeout some more performance by giving up multiple inheritance support, butthat's not a good reason to remove MI from C++. Why is a binary standardany different? [naturally the binary standard is only one step toward "true"software components] BS: C++ delivers what it promised. It cannot be expected to meetthe hype of every language and system claiming to be object-oriented orwhatever. C++ is a programming language, not a module specification languageor an operating system. It - like any other language - cannot be everythingto everybody. You can build "pluggable components" using C++,but that is not the primary aim of C++ and it takes work. Interoperabilityis a hard problem. People generally don't appreciate that only throughlots of work an lots of agreements between competing organizations caneven interoperability of C program fragments compiled by different compilersbe achieved. There has to be agreement on function calling sequences, datalayout, floating point arithmetic details, etc. C++ is harder than C, butnot much, because almost all of the hard problems are political ratherthan technical. The issue of multiple inheritance is completely separatefrom any issue of binary standards and interoperability of C++ compilers.I believe that the absence of MI in at least early versions of SOM reflectsnothing but a leaning towards the Smallatlk and Objective C among the initialSOM designers. In a language like C++, that relies on static type checkingof interfaces, some form of multiple inheritance is essential. The alternativeis warped code, unsafe interfaces, or both. CP: Do you have any new concept, idea, or feature that you arethinking of for a "next generation C++" and that you'd like toanticipate to us? [I understand you want C++ to be stable for a while;I guess that does not stop you from thinking to improvements, maybe evenimprovements on some implementation issues for existing features]. BS: My feeling is that when it comes to programming languages,people pay lipservice to experimentation and try to treat the field asa branch of mathematics or philosophy. However, I feel that the next generationC++ should come from real problems in real applications and from experimentationrather than speculation and polishing of the existing language. I findit much easier to describe what I have done and what I think of thingsI understand some of than trying to predict the future. I love ScienceFiction, but not when it masquarades as technical articles. I do think,though, that we have too many "true believers" and too few experimentalistsin our field. To improve our computer systems we must have lots of goodexperiments and tons of reliable data. From that can come the insightsthat allows us to determine what are the real problems and how to solvethem. Far too often, we just sit around philosophising about our feelings,opinions, and theories instead of making real progress. Reader's Map Several visitors who have readthis article have also read:BiographyCarlo Pescio holds a doctoral degree in ComputerScience and is a consultant and mentor for various European companiesand corporations, including the Directorate of the European Commission.He specializes in object oriented technologies and is a memberof IEEE Computer Society, the ACM, and the New York Academy ofSciences. He lives in Savona, Italy and can be contacted at pescio@eptacom.net. |
|
