www.digitalmars.com         C & C++   DMDScript  

c++.beta - Bit quiet here

reply James Mansion <james mansionfamily.plus.com> writes:
Time to give up and move on?

Walter - is there any chance of a roadmap of any sort, even
without dates?
Jun 06 2008
next sibling parent =?iso-8859-1?Q?Robert_M=2E_M=FCnch?= <robert.muench robertmuench.de> writes:
On Fri, 06 Jun 2008 14:44:37 +0200, James Mansion  
<james mansionfamily.plus.com> wrote:

 Time to give up and move on?

 Walter - is there any chance of a roadmap of any sort, even
 without dates?

Good point. I was wondering to if DMC is a dakota horse... Robert.
Jun 06 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
James Mansion wrote:
 Time to give up and move on?
 
 Walter - is there any chance of a roadmap of any sort, even
 without dates?

I generally do things that follow the interests of the people that use it.
Jun 14 2008
next sibling parent =?iso-8859-1?Q?Robert_M=2E_M=FCnch?= <robert.muench robertmuench.de> writes:
On Sat, 14 Jun 2008 23:21:58 +0200, Walter Bright  
<newshound1 digitalmars.com> wrote:

 I generally do things that follow the interests of the people that use  
 it.

That makes sense but I still think DMC is to valuable to leave it behind. I posted some questions in c++.windows-32-bit but no responses... without a good community DMC users are lost. :-( -- Robert M. Münch Management & IT Freelancer http://www.robertmuench.de
Jun 15 2008
prev sibling next sibling parent reply James Mansion <james mansionfamily.plus.com> writes:
So:

Is Boost fully working now?

What about other 'reference' toolsets like Poco, wxWidgets, ACE,
Qt?

I had thought that there was some planned activity over linker etc
to make that a maintainable part of the chain and make way for 64
bit?

There has certainly been some activity here (and in other fora)
relating to issues since the .51 reelase in January.

I don't quite know what to read into your reply!
Jun 23 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
James Mansion wrote:
 So:
 
 Is Boost fully working now?

No, mainly because nobody has expended the effort to do so.
 
 What about other 'reference' toolsets like Poco, wxWidgets, ACE,
 Qt?

wxWidgets is
 
 I had thought that there was some planned activity over linker etc
 to make that a maintainable part of the chain and make way for 64
 bit?

Going to have to do 64 bit sooner or later!
 
 There has certainly been some activity here (and in other fora)
 relating to issues since the .51 reelase in January.
 
 I don't quite know what to read into your reply!

Jun 23 2008
parent reply James Mansion <james mansionfamily.plus.com> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
 James Mansion wrote:
 So:

 Is Boost fully working now?


Doesn't that someone have to be you though? We're somewhat dependent on you to do all teh fixes, and pretty much all the triage, and without any activity here its impossible to determine what's going on. If, indeed, anything at all is going on.
 Going to have to do 64 bit sooner or later!

Indeed. Could hook up with LLVM maybe? That project could benefit from greatly a non-gcc front end. Do you still have a material interest in using a proprietary back-end? (Or indeed keeping the front end proprietary? I have no idea how you make your daily bread these days Walter - long time since we met with John H and Dave Mansell in Woolwich! But the BSD camp is a compiler short of a toolset at the moment.) James
Jun 24 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
James Mansion wrote:
 == Quote from Walter Bright (newshound1 digitalmars.com)'s article
 James Mansion wrote:
 So:

 Is Boost fully working now?


Doesn't that someone have to be you though?

Not necessarily. Most Boost developers spent a very large amount of time getting their libraries to work around the various compiler vagaries - time the vendor didn't invest. Trying to figure out why a Boost library fails usually requires a thorough understanding of that library - this is a big job for someone other than the library writer. Once the problem is reduced to a small test case (nearly all reduce to 10 lines or so), it can be posted to the DMC++ bugzilla.
 
 We're somewhat dependent on you to do all teh fixes, and pretty
 much all the triage, and without any activity here its impossible
 to determine what's going on.  If, indeed, anything at all is
 going on.
 
 Going to have to do 64 bit sooner or later!

Indeed. Could hook up with LLVM maybe?

I don't know what the state of LLVM is, or how ready it is, but it still would be a major project to hook up with.
 
 That project could benefit from greatly a non-gcc front end.  Do
 you still have a material interest in using a proprietary back-end?
 
 (Or indeed keeping the front end proprietary?  I have no idea how
 you make your daily bread these days Walter - long time since we
 met with John H and Dave Mansell in Woolwich!  But the BSD camp is
 a compiler short of a toolset at the moment.)
 
 James

Jun 24 2008
parent James Mansion <james mansionfamily.plus.com> writes:
 I don't know what the state of LLVM is, or how ready it is, but

 would be a major project to hook up with.

I think it will be a somewhat lesser task than building a 64 bit CG and your own linker and librarian and debugger interface though. Apple are using it for real. I'm really surprised you aren't monitoring it. Still, its your prerogative. James
Jun 25 2008
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Robert M. Münch wrote:
 On Mon, 23 Jun 2008 15:09:04 +0200, James Mansion 
 <james mansionfamily.plus.com> wrote:
 
 I had thought that there was some planned activity over linker etc

I'm mostly struggleing with DMC in that I have to compile all and everything to avoid linker problems. Not all libs can be converted to OMF format. So, the chain is: - Alter build environment to use DMC - Change source code to compile with DMC. Biggest problems is, that DMC doesn't look like MSVC to the pre-processor etc. Walter, can't you just add some compiler options where I can specify which MSVC version DMC should fake?

DMC's preprocessor is 100% standard compliant. I just cannot work up the desire to emulate various VC bugs in it. For portable libraries, this shouldn't be a problem, because they shouldn't be relying on VC compiler bugs.
 
 Somethinglike -msvc=6|7|8
 
 - Collect all necessary LIB files, try to convert them etc.
 
 All this is quite hard work even for just replacing MSVC with DMC. If 
 you compile open-source stuff from Unix it's even more work.
 
 I recently setup MingW with MSYS and all kind of stuff (not an easy task 
 as well) but now I can just compile linux projects with autoconf / 
 configure etc. Much less hassel...
 
 As much as I love DMC, as soon as you have to combine several projects 
 for your app, it's not an easy task.

I understand. I've tried in the past to make DMC match other compilers' buggy behavior, but it's a losing game for me as the bugs constantly shift. What has worked better is making it standard compliant.
Jun 24 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Robert M. Münch wrote:
 What I do at the moment as well. My sugestion is directed to avoid that 
 I have to add "|| defined __DMC__" at several places.

I understand, but I think it is just wrong for DMC to predefine _MSC_VER.
Jul 09 2008
prev sibling next sibling parent Arjan Knepper <arjan ask.me.to> writes:
Robert M. Münch wrote:
 On Mon, 23 Jun 2008 15:09:04 +0200, James Mansion 
 <james mansionfamily.plus.com> wrote:
 
 I had thought that there was some planned activity over linker etc

I'm mostly struggleing with DMC in that I have to compile all and everything to avoid linker problems. Not all libs can be converted to OMF format. So, the chain is: - Alter build environment to use DMC - Change source code to compile with DMC. Biggest problems is, that DMC doesn't look like MSVC to the pre-processor etc. Walter, can't you just add some compiler options where I can specify which MSVC version DMC should fake? Somethinglike -msvc=6|7|8 - Collect all necessary LIB files, try to convert them etc. All this is quite hard work even for just replacing MSVC with DMC. If you compile open-source stuff from Unix it's even more work. I recently setup MingW with MSYS and all kind of stuff (not an easy task as well) but now I can just compile linux projects with autoconf / configure etc. Much less hassel... As much as I love DMC, as soon as you have to combine several projects for your app, it's not an easy task.

It is a time consuming process in most cases. The usual recipe I use is: Does the software build with MSVC? If so: - generate the MSVC build environment if any. - Translate the compiler switches to DMC equivalent ones. - Grep the source tree to find the MSVC special sections (_MSC_VER). Most project redefine _MSC_VER to somthing else, in that case use the replacment symbol. I use the -l option on grep to list the affected source files. - Inspect the specials in each listed file and apply the __DMC__ (or replacment symbol) if neccessary. In most cases a few modication are still needed to build the the project with DMC. When the software dos not build with MSVC Does the software build with ANY compiler on win32? use the same recipe but replace _MSC_VER for the 'other' one. This usally implies much more work. When the software does not build at all on win32 generate the build environment on the supported target for a supported compiler. Copy it over to win32. Build with DMC and grep for specific target dependecies and stub them out with replacment onces. When the whole thing builds with the stubs, inspect the stubs and "implement" or "interface" them to the Win32api. This usually implies much much much more work. Third party libs: - Stay away a much as possible from converted coff2omf libs when they are not just simple standard conformant static C libs. - prefer to generate import libs from provided dll's. Most of the time this works best (use DMC's coffimplib.exe) Arjan
Jun 25 2008
prev sibling parent reply Arjan Knepper <arjan ask.me.to> writes:
James Mansion wrote:
 So:
 
 Is Boost fully working now?

No, there are quite some ICE's and other problems solved. It look more worse than in fact it is. Mainly because most boost libs use boost/test in their test suite. DMC has troubles with boost/test and as a result all tests using boost/test fail. Although the lib might work perfectly well with DMC.
 
 What about other 'reference' toolsets like Poco, wxWidgets, ACE,
 Qt?

Indeed wxWidgets is, there was some effort in porting ACE as well don't know the result/status.
 
 I had thought that there was some planned activity over linker etc
 to make that a maintainable part of the chain and make way for 64
 bit?

Well the linker is going to be more and more a problem, it has some SMP problems, and is easily pushed over other limits with todays software demands. 64 bits support would be really nice and a Linux/BSD port even more!! Arjan
Jun 25 2008
parent reply Christof Meerwald <cmeerw cmeerw.org> writes:
On Wed, 25 Jun 2008 16:57:45 +0200, Arjan Knepper wrote:
 Well the linker is going to be more and more a problem, it has some SMP 
 problems, and is easily pushed over other limits with todays software 
 demands.

If you are concerned about the linker, why not get your hands dirty, get the Open Watcom linker and adapt it to make it work with Digital Mars? It's not that much work (left) - in fact I started it some years ago and almost got there (see http://cmeerw.org/prog/owtools/), but have shifted focus since then. But I really don't see a reason why there is a need for two linkers when one of the linkers is Open Source (and written in C). Christof -- http://cmeerw.org sip:cmeerw at cmeerw.org mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org
Jun 25 2008
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Christof Meerwald wrote:
 If you are concerned about the linker, why not get your hands dirty, get the
 Open Watcom linker and adapt it to make it work with Digital Mars? It's not
 that much work (left) - in fact I started it some years ago and almost got
 there (see http://cmeerw.org/prog/owtools/), but have shifted focus since
 then.
 
 But I really don't see a reason why there is a need for two linkers when one
 of the linkers is Open Source (and written in C).

I really like how fast optlink is <g>.
Jun 25 2008
prev sibling parent reply James Mansion <james mansionfamily.plus.com> writes:
 But I really don't see a reason why there is a need for two

 of the linkers is Open Source (and written in C).
 Christof

Have you looked at uldar? (See http://www.ultimatepp.org/www$uppweb$download$en-us.html) I'm not sure that I find the speed of optlink to be a big deal in the grand scheme of things, but then I tend to produce lots of DLLs. It shouldn't be necessary to use assembler to get good linking performance on a modern system - a decent IO strategy and good algorithms will be fine.
Jun 27 2008
parent reply Christof Meerwald <NOSPAM-seeMySig cmeerw.org> writes:
On Fri, 27 Jun 2008 16:34:40 +0000 (UTC), James Mansion wrote:
 But I really don't see a reason why there is a need for two

 of the linkers is Open Source (and written in C).
 Christof


Have you looked at it? It says "uld COFF linker" which doesn't look like it would be of much use for Digital Mars at the moment... Christof -- http://cmeerw.org sip:cmeerw at cmeerw.org mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org
Jun 27 2008
parent James Mansion <james mansionfamily.plus.com> writes:
== Quote from Christof Meerwald (NOSPAM-seeMySig cmeerw.org)'s >
It says "uld COFF linker" which doesn't look like it would be of
much use
 for Digital Mars at the moment...
 Christof

Well, I *use* it, but fair cop I guess. I'm assuming the current situation is untenable. How far from usable is the OpenWatcom stuff? I used to like the Watcom compiler and toolset but it got so crufty that its been hard to justify any time at all.
Jun 30 2008
prev sibling next sibling parent =?iso-8859-1?Q?Robert_M=2E_M=FCnch?= <robert.muench robertmuench.de> writes:
On Mon, 23 Jun 2008 15:09:04 +0200, James Mansion  
<james mansionfamily.plus.com> wrote:

 I had thought that there was some planned activity over linker etc

I'm mostly struggleing with DMC in that I have to compile all and everything to avoid linker problems. Not all libs can be converted to OMF format. So, the chain is: - Alter build environment to use DMC - Change source code to compile with DMC. Biggest problems is, that DMC doesn't look like MSVC to the pre-processor etc. Walter, can't you just add some compiler options where I can specify which MSVC version DMC should fake? Somethinglike -msvc=6|7|8 - Collect all necessary LIB files, try to convert them etc. All this is quite hard work even for just replacing MSVC with DMC. If you compile open-source stuff from Unix it's even more work. I recently setup MingW with MSYS and all kind of stuff (not an easy task as well) but now I can just compile linux projects with autoconf / configure etc. Much less hassel... As much as I love DMC, as soon as you have to combine several projects for your app, it's not an easy task. -- Robert M. Münch Management & IT Freelancer http://www.robertmuench.de
Jun 24 2008
prev sibling next sibling parent =?iso-8859-1?Q?Robert_M=2E_M=FCnch?= <robert.muench robertmuench.de> writes:
On Tue, 24 Jun 2008 23:43:32 +0200, Walter Bright  
<newshound1 digitalmars.com> wrote:

 - Change source code to compile with DMC. Biggest problems is, that DMC  
 doesn't look like MSVC to the pre-processor etc.
 Walter, can't you just add some compiler options where I can specify  
 which MSVC version DMC should fake?

DMC's preprocessor is 100% standard compliant. I just cannot work up the desire to emulate various VC bugs in it. For portable libraries, this shouldn't be a problem, because they shouldn't be relying on VC compiler bugs.

Hi Walter, by "look like MSVC" I don't mean to implement the same bugs. I meant that pre-define macros should be the same as MSVC. So that the source-code is pre-processed as if MSVC would be used. If this would lead to pre-processing errors because MSVC has bugs and DMC not, I think it's perfectly OK to change the source and report those changes back to the project. What I do at the moment as well. My sugestion is directed to avoid that I have to add "|| defined __DMC__" at several places.
 I understand. I've tried in the past to make DMC match other compilers'  
 buggy behavior, but it's a losing game for me as the bugs constantly  
 shift. What has worked better is making it standard compliant.

Again, I don't DMC should mimic bugs. A lot would be gained if it just uses the same pre-defined macros. -- Robert M. Münch Management & IT Freelancer http://www.robertmuench.de
Jun 27 2008
prev sibling next sibling parent =?iso-8859-1?Q?Robert_M=2E_M=FCnch?= <robert.muench robertmuench.de> writes:
On Wed, 25 Jun 2008 16:22:34 +0200, Arjan Knepper <arjan ask.me.to> wrote:

 It is a time consuming process in most cases.

 The usual recipe I use is:
     Does the software build with MSVC?
 ...

Hi Arjan, thanks for showing us which process you use to get things compiled with DMC.
 Third party libs:
 - Stay away a much as possible from converted coff2omf libs when they  
 are not just simple standard conformant static C libs.

Yes, that's my experience as well. I just recently found out that the MingW linker can handle mostly everything available. I haven tested with OMF libs yet. But maybe it would be a good idea to use this linker than. Walter, is it really that hard to replace the linker? I know that Optlink is fast, has a lot of assembler and is a nice linker but it's a stranger in the world. Maybe using a different linker is an option. Does D produce OMF files as well? I still think that C/C++ compilers are needed for several years and it would help.
 - prefer to generate import libs from provided dll's. Most of the time  
 this works best (use DMC's coffimplib.exe)

Yes, but I'm not a fan of DLLs at all. That's why I try to compile the sources, create static libs and link everything together. It makes live for the user much more convinient. One EXE that's it. When I use scripting languages, I pack all the stuff into one DLL that can be called. -- Robert M. Münch Management & IT Freelancer http://www.robertmuench.de
Jun 27 2008
prev sibling next sibling parent =?iso-8859-1?Q?Robert_M=2E_M=FCnch?= <robert.muench robertmuench.de> writes:
On Tue, 24 Jun 2008 23:40:13 +0200, Walter Bright  
<newshound1 digitalmars.com> wrote:

 Not necessarily. Most Boost developers spent a very large amount of time  
 getting their libraries to work around the various compiler vagaries -  
 time the vendor didn't invest.

Has anyone any experience with the Comeau compiler stuff? Maybe this would help. http://www.comeaucomputing.com -- Robert M. Münch Management & IT Freelancer http://www.robertmuench.de
Jun 27 2008
prev sibling parent =?iso-8859-1?Q?Robert_M=2E_M=FCnch?= <robert.muench robertmuench.de> writes:
On Wed, 25 Jun 2008 23:33:39 +0200, Walter Bright  
<newshound1 digitalmars.com> wrote:

 I really like how fast optlink is <g>.

I too, but it's like driving a Porsche with 500 HP but only driving in a circle. You are fast but won't move. If the rest is driving somewhere else the 500 HP don't help. -- Robert M. Münch Management & IT Freelancer http://www.robertmuench.de
Jun 27 2008