• Bruno Medeiros (63/63) Aug 15 2005 Some minor bugs I noticed some days ago, in case it is of interest:
• Stewart Gordon (14/23) Aug 23 2005 True, but only those names that are unambiguous. If two imported

Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:

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


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 can be grouped together in heirarchies called packages. "
Typo in "heirarchies"



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



"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?



"-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?


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;
		}
	};
	


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

Stewart Gordon <smjg_1998 yahoo.com> writes:

Bruno Medeiros wrote:
<snip>

 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.