August 15, 2005
Some minor bugs I noticed some days ago, in case it is of interest:

# OVERVIEW :
C++:
	class Foo
	{
	    int foo(Bar *c) { return c->bar; }
	};

	class Bar
	{
	  public:
	    int bar() { return 3; }
	};
	
	
"return c->bar;" is missing the function call, it must be "c->bar()" in C++


# MODULES :
"Modules can be grouped together in heirarchies called packages. "
Typo in "heirarchies"


# EXPRESSIONS:
"foo = new char[][30];	// allocate 30 arrays of strings"
should be "an array of 30 strings" or "an array of 30 arrays of chars"


# MEMORY MANAGEMENT:
"Call gc.disable() before the smooth code is run, and gc.enable() afterwards. This will cause the gc to favor allocating more memory instead of running a collection pass."
Not "favor", but instead "force", no?


# MEMORY MANAGEMENT:
"-The uninitialized data that is on the stack will get scanned by the garbage collector looking for any references to allocated memory. Since the uninitialized data consists of old D stack frames, it is highly likely that some of that garbage will look like references into the gc heap, and the gc memory will not get freed. This problem really does happen, and can be pretty frustrating to track down.
 -It's possible for a function to pass out of it a reference to data on that function's stack frame. By then allocating a new stack frame over the old data, and not initializing, the reference to the old data may still appear to be valid. The program will then behave erratically. Initializing all data on the stack frame will greatly increase the probability of forcing that bug into the open in a repeatable manner"
This two caveats, are they not pretty much the same?

# C .h TO D MODULES:
Nested Structs: In the D way, is the following correct? (since no variable of the type of the anonymous struct is declared, unlike the C example)

	struct Abc
	{
		int a;
		struct
		{
			int c;
		}
	};
	

# CONVERTING C++:
Namespace using declarations: The D Way:

---- Another module ----
import Foo;
alias Foo.x x;

Redundant alias since import already brings the imported module scope into the local scope?




-- 
Bruno Medeiros
Computer Science/Engineering student
August 23, 2005
Bruno Medeiros wrote:
<snip>
> # CONVERTING C++:
> Namespace using declarations: The D Way:
> 
> ---- Another module ----
> import Foo;
> alias Foo.x x;
> 
> Redundant alias since import already brings the imported module scope into the local scope?

True, but only those names that are unambiguous.  If two imported modules declare things with the same name, each must be fully qualified unless an alias is used to bring it into the local scope.

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- a->--- UB@ P+ L E@ W++@ N+++ o K- w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.