Thread: Re: [Audacity-devel] HEAD win build broken -- as of 2:30PST Aug 5 (Page 2)
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: CN <mi...@sc...> - 2004-08-08 04:56:43
|
On Sun, 8 Aug 2004 00:39:10 -0400, Monty wrote: >On Sat, Aug 07, 2004 at 08:08:56PM -0700, Matt Brubeck wrote: >> Monty wrote: >> > On Fri, Aug 06, 2004 at 09:38:16AM +0200, Markus Meyer wrote: >> > >> > > > It's complaining about a legal declaration... >> > > > wxString prompts[count]; >> > > >> > > Just use >> > > wxString* prompts = new wxString[count]; >> > >> > Yes, the fix is easy enough. I also wanted to know the nature of what >> > MSVC++ didn't support. >> >> I think that MSVC++ is right. According to Stroustrup, the array bound >> in the above statement "must be a constant expression" (p 89). "gcc >> -pedantic" also gives an error on the above code. > >It's explicitly legal in C99 and has been long supported by many compilers. > >Monty If we want to get the efficiency of the original construct Monty used, in MSVC++ we can do: #include <malloc.h> ... wxString* prompts = (wxString*) alloca( sizeof(wxString) * count); And, of course, this does not need a delete[]. I think this is how the original construct is implemented in the supported compilers. I do not know if the above is portable enough; I would think it will work in all compilers. If we use this method in places where an object's scope needs to be only within that routine, it is a lot more efficient than using new[], especially for frequent and repeated new[] and delete[], since allocation and deallocation on the stack are almost without cpu cycles cost, and the problems of heap fragmentation and garbage collection are avoided. I think this is one of the reasons that Aud ends up using a lot of cycles in the long recording/playback processes (this is just a guess now). Cordially, Chacko |
From: <xip...@xi...> - 2004-08-08 05:06:02
|
On Sat, Aug 07, 2004 at 09:56:37PM -0700, CN wrote: > If we want to get the efficiency of the original construct Monty used, in MSVC++ we can do: > > #include <malloc.h> > ... > wxString* prompts = (wxString*) alloca( sizeof(wxString) * count); MSVC++ doesn't have alloca(), but I think it does have _alloca(). Regardless, my reason for doing that was convenience, not efficiency. At least in this case. Monty |
From: CN <mi...@sc...> - 2004-08-08 05:28:47
|
On Sun, 8 Aug 2004 01:12:02 -0400, Monty wrote: >On Sat, Aug 07, 2004 at 09:56:37PM -0700, CN wrote: >> If we want to get the efficiency of the original construct Monty used, in MSVC++ we can do: >> >> #include <malloc.h> >> ... >> wxString* prompts = (wxString*) alloca( sizeof(wxString) * count); > >MSVC++ doesn't have alloca(), but I think it does have _alloca(). > >Regardless, my reason for doing that was convenience, not efficiency. >At least in this case. > >Monty It compiles fine here with my MSVC++ 6.0 with the latest SP. The online reference does not show that alloca() but shows the _alloca(), however the library with malloc.h appear to support it fine. Cordially, Chacko |
From: Dominic M. <do...@au...> - 2004-08-09 06:45:19
|
On Aug 7, 2004, at 10:12 PM, Monty wrote: > MSVC++ doesn't have alloca(), but I think it does have _alloca(). FYI, we're currently using alloca() in AudioIO.cpp, so it must exist on Windows. It's possible that wx is defining alloca() to be _alloca() for us. - Dominic |
From: Vaughan J. <vjo...@co...> - 2004-08-03 21:11:43
|
I'm willing & able to build the Windows 1.2.2 versions, although I still have the MSVC++ 6.0 compiler. I can probably get it to build with the Toolkit, that has the 7.0 compiler. Do we want to try that or keep the 1.2.x lineage on the same compiler & upgrade compilers for the next release from HEAD? -Vaughan |
From: Alexandre P. <ale...@gm...> - 2004-08-04 08:22:34
|
On Tue, 03 Aug 2004 14:09:59 -0700, Vaughan Johnson <vjo...@co...> wrote: > I'm willing & able to build the Windows 1.2.2 versions, although I still > have the MSVC++ 6.0 compiler. I can probably get it to build with the > Toolkit, that has the 7.0 compiler. Do we want to try that or keep the > 1.2.x lineage on the same compiler & upgrade compilers for the next > release from HEAD? As for me, I'm interested in an ability to compile A. with the toolkit. But I have neither experience, nor skills :) Alexandre |