[boost] Re: GUI sublanguage ?
> Adobe has a tool called ADM - Adobe Dialog Manager, which is used in many > of their > programs. You can see the docs for ADM in (for example) the Acrobat SDK, > since > you can use ADM when writing plugins for Acrobat. > > In ADM, you define your dialogs in a text-based format, giving control > types, sizes, > and text, and ADM lays out the dialogs, and passes information back to > you based on > what the user does. > > The big advantage here is that all the layout "smarts" are in one place, > and they match > the IU guidelines of the platform that the program is running on. > > The disadvantage is that if you want to do something that is not > supported by ADM, > you have to call the platform APIs, and your portability is shot. After having followed this thread I wander if we are trying to reinvent the wheel. By googling a bit one can find plenty of "Gui Toolkits" and here I saw little of them. Not a word on Qt, for example. I never used it for an important project but they give a (good ?) solution for example to the layout issues discussed so far. If I should criticize them (as a lazy user who is in troble finding his way among all those features) if the fact that there are huge classes that probably need further decomposition of resposibilities. Anyway Qt make life simple for simple apps and provides something that scales quite well for larger projects (I haven't used it but I can use KDE as witness). So I would like to have a clearer idea of the difference between the goal of this thread and existing solutions (i.e. Qt). regards ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Questions on fixdec
I am very interested in the library as I am working in its
target field (i.e. financial applications).
Reviewing it though, I found that it does not really
support the scenarios I consider important.
IMHO in a financial application (please note below a
code example) there are two separate issues that require
two different approaches to implementation:
I1. Storage and representation of decimals, where specific
scale is desired and can/should be specified up-front.
Also desired is smaller size for these objects.
I2. Calculation, where maximum precision is desired
[And then speed, of course]
I'm afraid the present implementation does not do well on either
of these issues. The particular problems I see:
P1. Storage: far from optimal. To represent 18 significant decimal
digits the implementation would typically require 20 bytes
[where 8 should be enough].
Also: to specify scale on a per-type basis, I would have to
inherit from this class and re-code all needed constructors
and assignment and conversion operators.
P2. Calculations: precision is limited by same 18 significant
digits, and (main point) the rounding occurs *in process*
of calculations.
Please see below a code example. I'd love to hear everyone's take
on the issues I described.
Thanks & Best Regards.
Ilya Buchkin
MetaCommunications Engineering
mailto:[EMAIL PROTECTED]
PS
/// Code example: //
namespace my_accounting_application {
// this is how I want to STORE the data -
// in the database, and in the program when not doing any calculations,
// specifying the scale according to application, and minimizing space:
// (type parameterized by scale and rounding policy)
typedef boost::decimal<2,round_up> t_decimal_price;
typedef boost::decimal<5> t_decimal_unit_price;
typedef boost::decimal<10> t_decimal_quantity;
typedef boost::decimal<10> t_decimal_tax_rate;
struct t_invoice_item
{
std::string description_;
t_decimal_unit_priceitem_price_;// e.g. 0.0625 ($ per
each)
t_decimal_quantity quantity_;
boolis_taxable_;
};
struct t_invoice
{
t_customer* customer_;
std::vector invoice_items_; // 100 items maybe
t_decimal_price subtotal_; // e.g. 12345.55 ($)
t_decimal_price tax_; // e.g. 1064.80 ($)
};
struct t_customer
{
std::string name_;
t_decimal_tax_rate tax_rate_; // e.g. 8.625 (%)
};
// ...this is how I would like to code CALCULATIONS:
void recalc_totals( std::vector a_invoices )
{
for_each ( a_invoices, inv ) // (simplified iteration notation)
{
boost::max_precision_decimal tax = 0; // accumulate with max
possible precision, please!
inv->subtotal_ = 0;
for_each ( inv->invoice_items_, item ) // (simplified iteration...)
{
boost::max_precision_decimal item_total = item->quantity_ *
item->item_price_;
inv->subtotal_ += item_total;
if ( item->is_taxable_ )
tax += inv->customer_->tax_rate_ * item_total;
}
inv->tax_ = tax;// round it here
}
}
};
/// end code example
/
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] type_with_alignment.hpp on gcc 2.96
FYI, gcc 2.96 is an unsupported development version of 3.0.
http://gcc.gnu.org/gcc-2.96.html
On Fri, 3 Jan 2003 [EMAIL PROTECTED] wrote:
> I am not sure whether this is a problem with the RedHat 2.96 release of gcc
> only, as I do not have gcc 2.95 handy to test this with -it works fine with
> gcc 3.2. Something as simple as the following does not compile
>
> #include
> int main { return 0;}
>
> The compile errors are with the lower_alignment and max_align unions. This
> seems to be caused by BOOST_PP_NODE_ENTRY_256( BOOST_PP_FOR_P ) not
> expanding correctly.
>
> Anyone else come across this or have I not read a vital piece of
> documentation?
>
>
> ___
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>
>
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: #pragma once
Doesn't MSVC support pre-compiled headers? This will speed up compilation much more than '#pragma once'. Try creating a common header file which includes all of your project's header files, and have all source files include the common header, and compare compile times. > "#pragma once" is just an optimization issue. If a file is included a > second time in the same TU, a dumb compiler will re-open it and give it > to the preprocessor who strips its contents entirely because the include > guard is already defined. Re-opening + preprocessing takes little but > significant time. > > With the "#pragma once" the programmer just gives an hint to the > compiler that re-opening is unnecessary and ignores the #include > directive immediately. You see, there *is* a speed gain even in the > presence of canonical include guards. HTH, --craig ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Reflection Framework [was Serialization and Reflection]
> For fields, I do not think it is particularly useful to provide access > exclusively to the actual instance variables. It seems, however, that > access control specifiers of public, private, and protected are not > useful, however, because first of all, it seems that it would be > nearly impossible to enforce such control, and also I do not see how > it would be useful. There should really be no need to publish > anything but public fields. This really depends on the application. Here's a thought: perhaps we should distinguish between a reflection framework based on 'types' vs 'code'. Code analysis and source-to-source translation tools may want more information than just type metadata, and in particular, it may be useful for them to know the access control of members. A reflection framework for persistence will only need to know about types. At this point, I think it makes sense to focus on type introspection first, and perhaps later consider the more general case of code-level reflection. I'm game if folks really want the latter, tho. I would argue that a truly useful type introspection framework would know about all types, public or private. It won't be very useful for persistence otherwise. This may break encapsulation, but that's the nature of the beast. WRT fields, at one point you asked the question: why save the use-count in a reference counted string? Say you're creating a debugging/profiling tool which monitors objects: it may be very useful to know what the current use-count of a particular object is. I would like to see, if possible, *all* objects and types exposed; there could be further filtering and/or higher level abstractions built on top of this framework. --craig ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Reflection Framework [was Serialization and Reflection]
On Wed, 18 Dec 2002, William E. Kempf wrote: > > I don't know if there's a > > policy about library submissions depending on closed-source tools. I > > don't think there should be a problem (after all, most compilers Boost > > supports are closed-source), but it seems prudent to ask up-front. > > I'm confused. Above you said it was open-source, now you talk about it > being closed-source? Sorry for not being very clear. The EDG front-end is closed source: it's used to generate IL, which is then parsed by (I believe) closed-source IL transformation tools (I think EDG considers their IL format a trade secret), to human-readable PDB files. From there, everything is open-source. Since all the binaries are freely redistributable, as is the source (where it is provided), in my estimation the toolkit as a whole meets the Boost license requirements. But I'm not sure if my opinion is the one that counts. ;-) > > Finally, is there anyone interested in working on a reflection > > framework? Does anyone have other ideas on approaching this problem? Any > > comments at all? I'll consolidate the information and put them up on the > > Wiki board. > > I'm very interested in having a reflection library available, but I can't > afford any time to helping with the work, sorry. However, I'd suggest you > take into consideration XTI, which is an idea for reflection in C++ from > Bjarne Stroustrup (there's several links to this on the web, one of which > is http://www.klid.dk/arrangementer/XTI_kbh.pdf, do a Google search for > the others). I think his work on it has stagnated, at least from some > things I've heard from others, which is unfortunate. But I think his work > would be a great place to start from for a Boost reflection framework. I'm definitely looking into this. After educating myself, I was planning on contacting BS about the current status of his project. If anyone happens to know more information, or is in a position to find out more, please do so and/or let me know. TIA. > > Were talking exclusively about reflection now... I don't want this > > muddled with the serialization discussion. They are separate topics. :-) > > But they *can* be related. I know you can do serialization with out > reflection, but I think the serialization capabilities of Java show that > reflection can vastly simplify the implementation of a serialization > library. (Though with out language support you can't access the private > data of an object to make serialization automatic in C++.) I agree. OTOH, I think a full-fledged reflection library will be some ways off. We could start with a bare-bones system designed to explicitly support serialization, but I think it would slow down the adoption of the existing serialization effort, and I'd rather not stir up more controversy (unless there's a clear benefit to doing so, which I don't see). Once a reflection library is more-or-less in place, extending it to handle serialization will be relatively straightforward, whether with a brand-new design or adapting it to an existing library. HTH, --craig ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Reflection framework
On Wed, 18 Dec 2002, Yitzhak Sapir wrote:
> I think it is possible to implement a reflection framework using the
> preprocessor library. In much the same way that one of the links
> previously mentioned
> ( http://www.garret.ru/~knizhnik/cppreflection/docs/reflect.html ), a
> description system could be made. The difference is that unlike the
> example definition of the above link:
> We would have something more like the following:
>
> #define A_DESCRIPTION DESCRIBE_STRUCT(6, \
>(RTTI_(int, i, RTTI_FLD_PUBLIC), \
> RTTI_(char*, pc, RTTI_FLD_PUBLIC), \
> RTTI_(double, d, RTTI_FLD_PUBLIC), \
> RTTI_ARRAY(long, 10, larr, RTTI_FLD_PROTECTED), \
> RTTI_(A**, ppa, RTTI_FLD_PROTECTED), \
> RTTI_(A*, pa, RTTI_FLD_PROTECTED)));
>
> class A
> {
> IMPLEMENT_DESCRIPTION(A_DESCRIPTION);
> int x; // some member variable which is not described
> };
>
> This has the advantage that you don't to respecify everything twice, and
> yet, most of the serialization functions could be generated automatically
> from A_DESCRIPTION.
I agree. I don't like redundant data. We could provide a macro interface
as well as provide tools to automagically generate the metadata. A macro
interface could also be useful to customize the fields, as Jeremy
Maitin-Shephard mentioned (but so could source-to-source translation
tools).
However, IMHO, using the PP is much more difficult to program, debug, and
maintain. It's also less powerful than having access to the IL (eg: how
will this handle free functions and namespaces? how could it support
existing code bases?). We could keep it around as a lowest common
denominator option tho.
--craig
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: What should Serialization do?
Or propagating an exception over the network (eg: CORBA). On Sat, 14 Dec 2002, Ihsan Ali Al Darhi wrote: > that > > there is anything wrong with it - I just wonder if you've come > > upon some application that hasn't occurred to me. > > Besides Matthias example, here's another one. Suppose an illigal user tried > to log in to your network. Of course his (her) attempt will be saved. You > can save this info and know which user tried to do so. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Reflection Framework [was Serialization and Reflection]
On Tue, 17 Dec 2002, Aleksey Gurtovoy wrote: > I've been recently drafting some interfaces for purely compile-time > reflection framework. It will clearly need a compiler support to implement; > the current plan is to prototype it in GCC. It's an on-and-off project, > though :). Cool. Would you care to put them in the sandbox and/or email them to me? I'd like to take a look at them. thanks, --craig ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Reflection Framework [was Serialization and Reflection]
> > Were talking exclusively about reflection now... I don't want this muddled > > with the serialization discussion. They are separate topics. :-) > > > > Perhaps, but it would be quite disappointing if after going to the > whole trouble of implementing a reflection framework, we ended up with > one that was not usuable for basing a serialization library. I agree. My intention isn't to stifle discussion, only try to avoid confusion. Serialization and/or persistence is a primary motivator for me, so if it fails to do this, I would consider the project a failure. --craig ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Reflection Framework [was Serialization and Reflection]
> I don't really know. There are other truly open alternatives that > might be worth looking into, e.g. GCC_XML, and Synopsis/OCC (get it as > part of the Synopsis package at synopsis.sf.net). I've looked briefly at GCC_XML; I haven't seen Synopsis. In many ways I would prefer one based on gcc, but I think GCC_XML is GPL'd, which may clash with Boost's license policy. I'll look into both of these further. > My other comment is that Bjarne Stroustrup was working on a system > known as XTI that extracted this sort of info from the debug symbol > output of GCC. I am only saying this to make the point that many > people think better reflection capability for C++ is important. Wow, the man himself is working on this! That is very good news. I'm printing out his XTI papers as I type this. thanks! --craig ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Reflection Framework [was Serialization and Reflection]
> > A reflective framework could be in three stages: a preprocessing stage > > (which creates the reflection data), an optional code > > generation/transformation stage, then a compilation stage. In this sense, > > it would be both a compile and run-time framework. > Sounds like a great idea to me. A couple more questions. I'm afraid I don't have the time or expertise to create a full C++ compiler (tho it would be interesting to try using Spirit). If I were to base a reflection framework on PDT, its parser and toolset comes as binaries for the following platforms: alpha apple hp9000s700 linux rs6000 sgi32 sgin32 sgi64 solaris2 hitachi Windows t3e The actual PDT reflection library is open-source and portable. Would this be acceptable for submission to Boost? I don't know if there's a policy about library submissions depending on closed-source tools. I don't think there should be a problem (after all, most compilers Boost supports are closed-source), but it seems prudent to ask up-front. Also, it seems to me that PDT's license meets Boost's requirements. Can anyone verify this (I've appended it below)? Finally, is there anyone interested in working on a reflection framework? Does anyone have other ideas on approaching this problem? Any comments at all? I'll consolidate the information and put them up on the Wiki board. Were talking exclusively about reflection now... I don't want this muddled with the serialization discussion. They are separate topics. :-) TIA, --craig * ** Program Database Toolkit ** ** http://www.acl.lanl.gov/pdtoolkit ** * ** Copyright 1998-2002 ** ** Department of Computer and Information Science, University of Oregon ** ** Research Center Juelich, ZAM, Germany ** ** Advanced Computing Laboratory, Los Alamos National Laboratory ** * ** ** ** Permission to use, copy, modify, and distribute this software and its ** ** documentation for any purpose and without fee is hereby granted, ** ** provided that the above copyright notice appears in all copies and that** ** both that copyright notice and this permission notice appear in ** ** supporting documentation, and that the name of University of Oregon (UO), ** ** Research Center Juelich (ZAM), and Los Alamos National Laboratory (LANL) ** ** not be used in advertising or publicity pertaining to distribution of ** ** the software without specific, written prior permission. The ** ** University of Oregon, ZAM, and LANL make no representations about the ** ** suitability of this software for any purpose. It is provided "as is" ** ** without express or implied warranty. ** ** ** ** UO, ZAM, AND LANL DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE.** ** IN NO EVENT SHALL THE UNIVERSITY OF OREGON, ZAM, OR LANL BE LIABLE FOR ** ** ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER ** ** RESULTING FROM LOSS OF USE, DATA, OR PROFITS, WHETHER IN AN ACTION OF ** ** CONTRACT, NEGLIGENCE, OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN ** ** CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. ** ** ** * ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re:Serialization and Reflection
On Tue, 17 Dec 2002, Robert Ramey wrote: > A very interesting post. > > I also believe it is interesting to consider whether it is valuable > to make a system of reflection for C++. I'm not sure whether > it is or not - but it is interesting non the less. In particular we > would be interested in compile-time reflection as well as > runtime reflection. I found the links on your subject interesting. A reflective framework would certainly be valuable to *me*, and I suspect to a number of other people on this list, whom I've seen express interest. IMHO, reflection is the best thing about Java, and one that is quite useful and generally applicable, particularly with serialization and persistence. I'm not arguing we should implement a serialization engine via a reflective framework for C++; I think we're in agreement that the serialization engine is at a much lower layer. A reflective framework could simply be used to automate [hopefuly transparently] much of the tedium (eg: read/write methods used by the serialization engine). Can you elaborate on compile-time reflection? We have the type-traits library, which may be an example what you have in mind. But this will always be limited without further compiler support. It would be ideal to see some kind of typeof operator added to the C++ standard. In the meantime (which could be a loong time ;-), I'd like a workable reflection framework. Whether it belongs to Boost is certainly an open question, however. A reflective framework could be in three stages: a preprocessing stage (which creates the reflection data), an optional code generation/transformation stage, then a compilation stage. In this sense, it would be both a compile and run-time framework. > >Second, in terms of Serialization, I'm willing to create a portable, > >efficient binary archiver based on CDR (the format used by CORBA). Since > >I'm lazy, I will probably steal most of the code from ACE/TAO > >(http://www.cs.wustl.edu/~schmidt/ACE.html). Note that CDR has minimal > >overhead (eg: it has variable byte-ordering, so byte swapping may not be > >necessary). If there's interest, let me know. > > There was much interest in implementing XDR. I believe that initially > it proceeded rapidly but bogged down because it depended on the > existence of some code shipped only with unix. Ultimately, implemenation > of a portable binary stream, requires specific coding for each machine > architecture. This makes the task larger than it first appears. ACE has been ported to many platforms. It comes down to a fairly straightforward, if tedious, refactoring. At bottom, it's only software. ;-) In any case, I'll wait at least until the serialization interface solidifies a bit more. cheers, --craig ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Serialization and Reflection
I have a couple thoughts on these topics... First, I found what appears to be a very useful reflection library called the Program Database Toolkit (PDT) at http://www.cs.uoregon.edu/research/paracomp/pdtoolkit/. In brief, it's free, uses the EDG front-end to generate IL, has a tool to convert IL to a human-readable format (called PDB), and finally provides a library (DUCTAPE) for accessing the PDB files via a reflective API. Their DUCTAPE API link seems to be broken, so I've attached it (or you can try http://www.harperperras.com/~craigp/ductape_primer.html). I don't know if it's possible to create a reflection library for C++ without either resorting to external tools like the PDT or forcing the user to do much of the work (eg: macros, like this library does http://www.garret.ru/~knizhnik/cppreflection/docs/reflect.html). Personally, I'd like it to be as transparent as possible (eg: so it could work with an existing code base without extensive modification). Second, in terms of Serialization, I'm willing to create a portable, efficient binary archiver based on CDR (the format used by CORBA). Since I'm lazy, I will probably steal most of the code from ACE/TAO (http://www.cs.wustl.edu/~schmidt/ACE.html). Note that CDR has minimal overhead (eg: it has variable byte-ordering, so byte swapping may not be necessary). If there's interest, let me know. --craig ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
