Error: getenv cannot be interpreted at compile time

Paul via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Tue Feb 17 12:06:14 PST 2015


On Tuesday, 17 February 2015 at 19:35:27 UTC, H. S. Teoh wrote:
> On Tue, Feb 17, 2015 at 07:17:41PM +0000, Paul via 
> Digitalmars-d-learn wrote:
>> I'd like to create a Terminal using terminal.d and make it 
>> available
>> across several source files (as a global rather than having to 
>> pass it
>> around) but when I define it like this in global scope:
>> 
>> Terminal Screen = Terminal(ConsoleOutputType.cellular);
>> 
>> I get this error:
>> 
>> Error: getenv cannot be interpreted at compile time, because 
>> it has no
>> available source code
>> 
>> I don't understand the error and Google doesn't help - can it 
>> be fixed
>> or am I just using the wrong approach?
> [...]
>
> The problem is that the Terminal constructor reads runtime 
> information
> from the OS, so it cannot be run at compile-time. What you need 
> to do is
> to initialize it at runtime inside a static this() block:
>
> 	Terminal* screen;
> 	static this() {
> 		*screen = Terminal(ConsoleOutputType.cellular);
> 	}
>
> Note that you have to use a pointer, because the Terminal 
> struct does
> not allow default construction of a Terminal.
>
> However, this isn't the end of the story... because the Terminal
> destructor also resets the terminal back to its original state 
> --
> otherwise after the program exits, you'll be stuck in cellular 
> mode,
> which may not be very nice on some systems where the shell will 
> get very
> confused (or rather, the user will see gibberish and not 
> understand
> what's going on).
>
> So the *correct* approach is to initialize the Terminal struct 
> in
> main(), so that when main() exits it will clean up properly:
>
> 	Terminal* screen;
> 	void main(string[] args) {
> 		// Create the Terminal here
> 		auto term = Terminal(ConsoleOutputType.cellular);
> 		screen = &term;	// so that everybody else can see it
>
> 		... // main program goes here
> 	} // Terminal will clean up properly here
>
> It's a bit ugly, but it should work. At least, that's what I do 
> in my
> own programs that use terminal.d. :-)
>
>
> T

Got it, I thought it might be something like this but when I 
tried to do:

Terminal screen;

...and initialise it later it failed because of the disabled 
default constructor.

There doesn't seem to be an alternative to using a pointer as 
it's rather a large struct to pass to functions as is!

which was falling


More information about the Digitalmars-d-learn mailing list