Hi Christian, Christian Schladetsch wrote:

It is certainly untrue to claim that DirectX is not relevant to C++. I do not think, and many others would agree, that OpenGL is a real alternative.

I have no wish in turning this into a flame war of DX vs GL. Whatever. I simply wanted to raise the idea of a boost::directx or boost::microsoft::directx namespace, to house common solutions.

The reality is that DirectX is here, it is supported by manufacturers, it is needed by C++ developers, and it will stay here.

The idea to have a proper C++ interface for DirectX sounds a good one indeed, but does it have to be in boost to be widely useful for C++ folks out there? I personally do not see that to be a requirement for what you propose. What about creating a separate open source project and put it on e.g. SourceForge? It could be licensed under the Boost Software License, and have quality standards similar to Boost. However I do not see something like that as a part of boost itself for the following reasons: - Wrapping only one proprietary API has no precedents in boost libraries. - Reasonable portability is a must. - Libraries are proposed and accepted in boost with eventual standardization in mind. An interface to a specific proprietary API doesn't fit here. Nevertheless, I do support your initiative to provide a C++-friendly interface for DirectX in general, and hope you continue your work on this subject for the benefit of the whole C++ community. With Kind Regards, Gevorg

Christian Schladetsch wrote:

Hi Gevorg,

I agree that in terms of "being eventually accepted as a C++ standard", any idea of boost::microsoft or boost::directx is deemed to fail.

However, there are many boost libraries that currently exist and have no chance in hell of being accepted into the C++ standard.

Cheers, Christian

Yes, there are such libraries in boost, but the reasons they are not going into standard are different. Some of them are simply superseded by language features, like boost.assign and boost.concept_check. Others (most?) are not mature enough and/or established practice yet to be proposed for standards commitee consideration, but have no fundamental reason they can't be ready for that at some future point. The few others left - boost.mpi and boost.python come to mind, are unlikely to ever make their way into the C++ standard, I agree, but they are at least portable and wrap non-proprietary interfaces. Best Regards, Gevorg

Christian Schladetsch wrote:

To: boost@lists.boost.org Sent: Sunday, June 7, 2009 6:42:17 PM Subject: Re: [boost] boost::directx?

...

The few others left - boost.mpi and boost.python come to mind, are unlikely to ever make their way into the C++ standard, I agree, but they are at least portable and wrap non-proprietary interfaces.

Christian

The reply came empty. Could you please resend the content? Regards, Gevorg

Gevorg Voskanyan wrote: [snip]

Others (most?) are not mature enough and/or established practice yet to be proposed for standards commitee consideration, [snip]

It makes one wonder how languages such as C# or Java managed to have infinitely more extensive standard libraries without existing maturity and/or established practice of those libraries =(

I have only remote familiarity with languages such as C# or Java from technical point of view, but the differences between those languages and C++ in how they were created and evolved are common knowledge, IMO.

OK, I hate to go off-tpoic here but WTF? How can you claim to be a C++ expert and not have intimate knowledge of C# and.or Java? I'm not a "boost expert", but I can write a language when I want to, and I certainly grok the differences between the CLR and Java JVM. ???

Ok, Christian, I don't really get why your reply is so negative. At least it feels that way.

Hang on; it was you that put yourself out there to judge my comments. I didn't ask you to. Thanks for your supportive remarks regarding DirectX, but really my position stands on its own merit or it doesnt irrespective of your comments. And you do nothing for me if you dont understand the JVM. Anyway, I'll try answer your concerns, however off-topic.

I didn't say I can't have the necessary knowledge of C# and/or Java to do whatever my job would require, I just say that I didn't invest any time for that yet because there was no such necessity. Nor had I found that to be a valuable investment to do that on my free time.

Whatever. Just hey, if you put yourself up as an expert, don't knock yourself down in the next phrase. It makes everyone look bad. Christian.

But don't make personal insults, it doesn't do any good to you.

My apologies. No offense intended. I am just weary of perceived auto-ney-sayers.

Gevorg

Christian

Hello, This is my first mail, so I hope I have sent it to the right address :) I am using the Units library for Dimensional Analysis. So far it is very useful. Up till now I am using it in a hard-coded/compile time way as in a test.cpp. My inteterst is in using Units as part of a larger run-time system so I need some way of making my code more flexible. Lambda library is an option here but I would also like to create units and quanties from string input as well as being able to parse these strings to units and then store the units in a database. Can I use Spirit (and Serialization) for these features? Maybe the functionality already exist, and I have not found it. best regrads Daniel J. Duffy

Hartmut, I would like to generate well-formed units and create expressions of the followiong kinds: Examples of unit expressions: 1. 2m + 15m*32s/16s = 32m. 2. 3m*7s + 2m*10s/5m = 21m + 4s -> ERROR. Can't add meters to seconds. The second group looks more tricky. Examples of simplification: 1. (x-2)^2 + 4x^2 - 2^x + 1 = 5x^2 - 8x + 10 2. x^2 + 7x + 10 = (x + 2)(x + 5) 3. (a + b)(a - b) = a^2 - b^2 4. sin(x)^2 + cos(x)^2 = 1 5. 2sin(x)cos(x) = sin(2x) One tricky part is for example #5 where the code needs to 'know' trigonometry. best regards Daniel ________________________________ From: boost-bounces@lists.boost.org on behalf of Hartmut Kaiser Sent: Mon 08-06-2009 01:46 To: boost@lists.boost.org Subject: Re: [boost] [Units & Spirit] libraries

I am using the Units library for Dimensional Analysis. So far it is very useful. Up till now I am using it in a hard-coded/compile time way as in a test.cpp.

My inteterst is in using Units as part of a larger run-time system so I need some way of making my code more flexible. Lambda library is an option here but I would also like to create units and quanties from string input as well as being able to parse these strings to units and then store the units in a database.

Can I use Spirit (and Serialization) for these features? Maybe the functionality already exist, and I have not found it.

Sure Spirit is your friend for all parsing and output generation needs. What did you have in mind? Regards Hartmut _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Thanks John for the response. I am new here, so I need to start a new thread. I suppose it's on www.boost.org on how to do it? Daniel ________________________________ From: boost-bounces@lists.boost.org on behalf of John Phillips Sent: Mon 08-06-2009 18:42 To: boost@lists.boost.org Subject: Re: [boost] [Units & Spirit] libraries Daniel, One general thing, first. At least on my news reader, this conversation with Hartmut appears in the middle of a long thread on something else entirely. You may want to start it as a separate thread to increase participation. Daniel J. Duffy wrote:

Hartmut, I would like to generate well-formed units and create expressions of the followiong kinds:

Examples of unit expressions: 1. 2m + 15m*32s/16s = 32m. 2. 3m*7s + 2m*10s/5m = 21m + 4s -> ERROR. Can't add meters to seconds.

So, you want this to happen at run time, or at compile time? At compile time, I think you are already set with the Units library. At run time, there are examples with the library that would help. If parsing the input is your concern, then Spirit is a good choice. (Spirit 2 is even better, by the way.) Using the two together, you could write a program where a user enters your example lines and gets correct responses.

The second group looks more tricky.

Examples of simplification: 1. (x-2)^2 + 4x^2 - 2^x + 1 = 5x^2 - 8x + 10 2. x^2 + 7x + 10 = (x + 2)(x + 5) 3. (a + b)(a - b) = a^2 - b^2 4. sin(x)^2 + cos(x)^2 = 1 5. 2sin(x)cos(x) = sin(2x)

One tricky part is for example #5 where the code needs to 'know' trigonometry.

As far as I can tell here, you are looking for a program that does symbolic algebra. If that is true, then I don't think boost has a complete solution for you. Writing the parser for the input with Spirit wouldn't be that bad, but writing the processing engine that matches patterns and does simplifications is not covered by any current Boost libraries. I don't recall seeing anyone poll for interest on this, so I don't think there is even a partial library in the sandbox. Would you want this at run time, compile time, both? I haven't tried to write it, but I think a pure compile time implementation would be prohibitively slow. For a pure run time solution, you might consider linking to already existing solutions, such as Maple or Mathematica.

best regards

Daniel

John _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2009/6/8 Daniel J. Duffy <dduffy@datasim.nl>:

Thanks John for the response. I am new here, so I need to start a new thread. I suppose it's on www.boost.org on how to do it?

This has nothing to do with boost. Its a email thingy. You most likely marked a message at you email client and clicked "reply to" rather than "new message". Your email client has thus added some meta data to your email, which you didn't intend. -- Maik

As someone who also uses DirectX and boost, I might as well throw in my 2 cents. It's true that OpenGL is pretty much non-existant as far as modern 3d graphics is concerned. On the other hand, it's true that boost's primary purpose is portability. It's nice to have cool libraries of platform specific stuff that use modern c++ design, but boost can't just turn into a hodgepodge of every useful library ever that uses modern c++ design techniques. It's true that having a library be "in" boost will dramatically increase its visibility and usage since by definition that means it's met the community's "seal of approval". But the very fundamentals of what goes into that seal of approval is what you're trying to circumvent by including it directly into boost as boost::directx. There are other platform specific things in boost, there's no doubt. Look at boost::asio::windows::overlapped for example. The difference is that there's an entire infrastructure surrounding it that provides access to basic functionality in a cross platform way. If you could implement a basic cross platform 3d library that uses directx on the windows backend and opengl on any other backend then you'd be onto something, and the you'd be justified in making a boost::graphics::windows::directx namespace with everything in the world you wanted. This is a _ton_ of work however, and it sounds like you have no interest in doing anything related to OpenGL or any non-windows platform. That's understandable, but maybe there's someone else in the community who could assist with that. But ultimately the bottom line is that boost is what it is, which is a cross platform library in the same sense that STL is a cross platform library and that C++ is a cross platform language. Assuming you decide to abandon the idea of including this code into boost due to not wanting to find the people / time / motivation to provide a cross platform infrastructure around it, then you're right that the DirectX community will lose out on a potentially valuable library. But it's easy to underestimate the importance of cross platform until you start working on something cross platform yourself.

Thanks for all your remarks. I didn't just barge in and think "oh hey, why didn't anyone else think of this". I knew that many people had thought of it before, and wanted to do it before.

Even so, it was worth re-raising. I knew from the lag between my orginal post and when it was visible on the list (hours!) that it was debated by the monitors to even present the idea for fear of just introducing noise to the list.

I don't believe so, we (the moderators that is) aren't hanging on every email waiting for the next post to moderate: in fact I approved your message as soon as I saw it first thing that morning :-)

I don't want to add noise. I was and am honest in my suggestions. And I will raise them again.

Well... suggesting a new library is never noise, even if it often proves more difficult to convert people to your point of view than you expect! What I'm not sure about, is exactly what you're proposing here: we don't normally accept non-portable libraries (hence the um... intense discussion), and we don't normally open new namespaces either unless there's a concrete piece of code to put in there (i.e. something that's been reviewed and accepted - the namespace and other packaging issues are often things that need discussing in the review). However.... I seem to recall once upon a time when Beman set up Boost's original "rules" that we were open for *examples* and/or proof of concept ideas that advance C++ programming in some way, we just seem to have moved away from that with our more recent focus on fully formed libraries. So I guess in that context, something like "here's how Boost can improve your DirectX code", might be a useful addition somewhere, I'm just not sure where! Anyhow, that's just me thinking aloud and definitely without a moderators hat on :-) Regards, John.

Christian Schladetsch wrote:

Gevorg Voskanyan wrote:

...

The idea to have a proper C++ interface for DirectX sounds a good one indeed, but does it have to be in boost to be widely useful for C++ folks out there?

No, it doesn't.

But if it didn't have a boost:: prefix, it wouldn't have the cross-company oomf that is needed to make it a worthwhile intellectual goal.

I can understand that.

The point of boost:: is to be a quasi-standard. I recognise that. That is why I am here, arguing for a DirectX namespace within boost, rather than elsewhere making Yet Antother DirectX Wrapper.

Are the other wrappers good enough from C++ (or boost, for that matter) point of view? If not, then it might be worthy to make an improvement in that area. That was my point. YMMV

I have as much interest in wrapping DirectX as I have in arguing its merits against OpenGL.

Even so, there are things you need to do, like vertex declarations, that are required. These can be helped with mpl. There are other things that boost can give DX users as well, and these should be shown to people.

In the form of examples in mpl, perhaps?

That is my point. That is only my point. I know it's not "pure boost", but meh.

I guess you'll have a hard time convincing the other boost guys to have a top-level boost library that represents a wrapper of DirectX API, including myself, for the reasons already outlined. Sorry.

Christian.

Best Regards, Gevorg

Christian Schladetsch wrote:

DirectX doesn't need to be "wrapped", other than maybe using com_ptr. That is not my point.

My point is that there are structures and techniques that are general and useful for DirectX coders. These things should be in a common namespace.

Denying this reality does nothing but remove boost from reality.

I don't think anyone denies that. What we don't seem to agree on is whether that common namespace should start with ::boost::

Cheers, Christian.

Regards, Gevorg