Re: Namespaces (was: string vs. LString)
> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes: Allan> Asger seems to want to make extensive use of namespaces and to Allan> a certain extent I can see that as being a good way to enforce Allan> the notion of ownership to the various modules. So we could Allan> have a gui namespace and an Inset namespace among others. If Allan> we then use namespaces in our code we can use namespaces from Allan> stl (which involves using different headers). Well, I see it as good but not necessarily required if we do not want to lock out a number of compilers... JMarc
Re: Namespaces (was: string vs. LString)
> Asger seems to want to make extensive use of namespaces and to a certain > extent I can see that as being a good way to enforce the notion of > ownership to the various modules. So we could have a gui namespace and an > Inset namespace among others. If we then use namespaces in our code we > can use namespaces from stl (which involves using different headers). Yes, I would like to use namespaces more. My feeling is that the bad things about global functions and variables does not exists anymore when you have namespaces. Suddenly, there is nothing wrong with having global functions and variables, and this change opens up some methods of coding that were previously packed away as bad coding style. With namespaces, I feel it's easier to let the code express what things are. For instance, the encoding facility is a global means of performing encoding conversions, that does not depend on any state or context. So I don't see why this feature should not just be exactly that in the code: an independent global function that does the conversion. Regarding whether we should *require* support for namespaces from the compiler or not: I have no real opinion on this. I'm sure that we can make things work without proper namespace support, and that is a good thing. The important thing is that the developers will be able to exploit the concept of namespaces, and if their compiler is up to it, get the extra safety from the compiler. I find it hard to make a list of things that we want from the compiler in advance. I'm more into the lazy style: Just code, and then take care of the problems when they appear. That's what we have been doing so far, and it seems to work pretty well. Of course, we are demanding more things from the compilers now, and it might turn out that we have to set some minimum requirements, but until we know more about the problems, it's hard to say what those are. Greets, Asger
Re: Namespaces (was: string vs. LString)
On Thu, 8 Apr 1999, Jean-Marc Lasgouttes wrote: > > "Allan" == Allan Rae <[EMAIL PROTECTED]> writes: > > Allan> # We still need portability to other platforms of course but we > Allan> can draw a line and say "it must support namespaces" or > Allan> whatever else we desire. We can probably get away without > Allan> partial specialization of templates. > > Could you explain why we need those namespaces? I understand what they > are in general, but we could probably live with std:: being the same > as the glabal namespace, if we choose names correctly. Well, I was trying to start a discussion about what we needed from the current standard and what we could live without. Asger seems to want to make extensive use of namespaces and to a certain extent I can see that as being a good way to enforce the notion of ownership to the various modules. So we could have a gui namespace and an Inset namespace among others. If we then use namespaces in our code we can use namespaces from stl (which involves using different headers). > Other than that, I agree that we should draw a line somewhere. But we > should be careful to draw it at the right place. And remember that > many people need to compile on the platform compilers and try to > support at least the latest version of these compilers. Absolutely. Allan. (ARRae)
Re: Namespaces (was: string vs. LString)
> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes: Allan> # We still need portability to other platforms of course but we Allan> can draw a line and say "it must support namespaces" or Allan> whatever else we desire. We can probably get away without Allan> partial specialization of templates. Could you explain why we need those namespaces? I understand what they are in general, but we could probably live with std:: being the same as the glabal namespace, if we choose names correctly. Other than that, I agree that we should draw a line somewhere. But we should be careful to draw it at the right place. And remember that many people need to compile on the platform compilers and try to support at least the latest version of these compilers. JMarc
Namespaces (was: string vs. LString)
On 29 Mar 1999, Lars Gullik Bjønnes wrote: > We need to introduce namespaces rather soon. > Lgb Perhaps we should make a decision as to what compiler capabilities we require. By the time LyX-1.1 is finished and stable enough to release there will probably be another gcc released and egcs will also be better. So perhaps we should make those the standard now and forget about gcc-2.7.2 and its contemporaries and concentrate on getting better code written instead of compatability#. That would also be a benefit for me since I could avoid having to reinstall gcc-2.7.2 and just stick with the two compilers I have now instead of the old 4 compiler installation I used to have. Points: Anyone using egcs should be using the latest or latest - 1. It is experimental after all and egcs-1.0.3a has a few flaws. Namespaces are handy and extensively used in the STL so it would make sense to exploit them rather than try to work around them. Allan. (ARRae) # We still need portability to other platforms of course but we can draw a line and say "it must support namespaces" or whatever else we desire. We can probably get away without partial specialization of templates.
Re: string vs. LString
On Mon, 29 Mar 1999, Asger Alstrup Nielsen wrote: > The Inset base class. Unfortunately, I'm not feeling too well at the > moment (something with my throat), so I have not done my homework yet. > Sorry to keep you waiting for my proposal. Take your time. This is another very interesting part of the new design that deserves another long thread. Alejandro
Re: string vs. LString
On Mon, Mar 29, 1999 at 12:49:19PM +0200, Asger Alstrup Nielsen wrote: > The Unicode.h file does not exist yet. Amir wrote an excellent script to Actually, my script is just good. I think only Keanu Reeves writes *excellent* scripts :) > convert the unicode database to a C++ file, but the last iteration is > missing. Anyway, Amir, what was the link to the file once again? Then > Lgb or I can hack it up and put it into the tree. It's at http://www.voth.chem.utah.edu/~karger/with.txt and without.txt. Without doesn't have the long text description of each unicode character, so it's about 60% the size of with. I realized I could've scp'ed this to nazgul instead, but I guess that's not any more convenient for asger. > > I want us to get the base for all this put firmly into place pretty > > soon, so that we can begin the implementation of the new buffer > > structure. (what remains to be discussed?) > > The Inset base class. Unfortunately, I'm not feeling too well at the > moment (something with my throat), so I have not done my homework yet. > Sorry to keep you waiting for my proposal. Ah. I had that last week. I wonder how it got to denmark so quickly. I guess I need to wash my hands before typing. -Amir
Re: string vs. LString
> If I understand you correctly, you want us to use "string" in all > places where we today uses "LString". Is that correct? If so I think > we should make the switch right away. Yes, please go ahead and do that change. (This is irrespective of the current discussion about whether InsetChunk should use LString or not.) > Concerning you comment in 2.1.1 about the lack of conversions from > numbers and floats to strings: that is why we have stringstream. Ok, I didn't notice that one. > I would hope that some of the string mangling functions in lstrings > could be removed. Hopefully all of them... ad. name change... yes > perhaps, but before we do this and the paramterizing you mention is to > try to get rid of all the unneeded functions therein. Yes, that's reasonable. > Also you say something about the ANSI C standard header , it > is a perfect valid header, but when used from ANSI C++ it should be > called as . Hopefully will we be able to use almost no > functions from it. Yes, we should use the headers without ".h". Those are the standard headers. The ".h" headers are non-standardized and varies from compiler to compiler. > Is your intention that LChar should be LString::value_type and not > string::value_type? If so, a small change in LString.h is needed. LChar should be either char or wchar_t according to our LString compilation flag. So, yes, LChar should be LString::value_type. > And: where is the Unicode.h you mention? And what is it supposed to > decleare? > > glyphType() > decomposeGlyph(); > lowercase(); > uppercase(); Yes. The titlecase() one was dropped again, because the memory overhead of the thing is bigger than the benefit of it. The Unicode.h file does not exist yet. Amir wrote an excellent script to convert the unicode database to a C++ file, but the last iteration is missing. Anyway, Amir, what was the link to the file once again? Then Lgb or I can hack it up and put it into the tree. > I want us to get the base for all this put firmly into place pretty > soon, so that we can begin the implementation of the new buffer > structure. (what remains to be discussed?) The Inset base class. Unfortunately, I'm not feeling too well at the moment (something with my throat), so I have not done my homework yet. Sorry to keep you waiting for my proposal. > We need to introduce namespaces rather soon. I think we can delay this one a bit. > It seems that the current devel lyx is not completely useless, as I > used it to read the encodings.lyx. Great. Greets, Asger
Re: string vs. LString
>> Lars Gullik Bjønnes writes: LGB> glyphType() decomposeGlyph(); lowercase(); uppercase(); titlecase(). Lgb
string vs. LString
Asger, If I understand you correctly, you want us to use "string" in all places where we today uses "LString". Is that correct? If so I think we should make the switch right away. Concerning you comment in 2.1.1 about the lack of conversions from numbers and floats to strings: that is why we have stringstream. Easy to use and a lot safer than scanf (et.al.) I would hope that some of the string mangling functions in lstrings could be removed. Hopefully all of them... ad. name change... yes perhaps, but before we do this and the paramterizing you mention is to try to get rid of all the unneeded functions therein. Also you say something about the ANSI C standard header , it is a perfect valid header, but when used from ANSI C++ it should be called as . Hopefully will we be able to use almost no functions from it. Is your intention that LChar should be LString::value_type and not string::value_type? If so, a small change in LString.h is needed. And: where is the Unicode.h you mention? And what is it supposed to decleare? glyphType() decomposeGlyph(); lowercase(); uppercase(); I want us to get the base for all this put firmly into place pretty soon, so that we can begin the implementation of the new buffer structure. (what remains to be discussed?) We need to introduce namespaces rather soon. It seems that the current devel lyx is not completely useless, as I used it to read the encodings.lyx. Lgb
