"Close Window" tutorial errors

[Karlos]

Any particular reason to prefer AllocMem() / FreeMem() over AllocVec() and FreeVec()?

At least with the latter you can forget how big the allocation was and exec remembers for you.

[Karlos]

That wasn't a criticism, btw :-)
I just figured AllocVec() / FreeVec() were more akin to malloc() and free() for those familiar with C but new to AmigaOS...

[Karlos]

Sidewinder wrote:
Honestly, resource tracking is cool, and malloc() works great for most things on the Amiga such as reserving space for structures, but if you are trying to reserve memory for things like graphics or sound you will need to use the AllocMem() or AllocVec() calls as they allow you explicitly specify that you want to reserve graphics (chip) memory.

I have my own memory class for this (and other low-level memory related stuff) in C++ :-)
The class wraps AllocVec(), tracks allocations (safely freeing anything on exit) and supports features such as cache alignment and what not..

OOP rules :-)

[Karlos]

Well, that would be nice, but it's not exactly that way in AmigaOS.

AmigaOS was written in C, so the C++ style inheritance rules don't exactly apply.

However, the designers did go for the compositional approach, so the first member of struct IntuitionBase is struct Library (any extended library type has struct Library as it's first member).

This means that although not strictly correct from a purist point of view, the following works

struct IntuitionBase* IntuitionBase;

struct Library* p = (struct Library*)IntuitionBase;

This led to a small problem I found in Storm C++ where, due to the redundant 'struct' keyword, the compiler complained about the variable IntuitionBase ( a pointer to an IntuitionBase structure) having the same name as the object...
Easily fixed, but bizzare and unexpected :-)

[Karlos]

itix wrote:
Advanced programmer should prefer AllocPooled() call over AllocMem()/AllocVec() calls IMO. No more memory leaks (just remember DeletePool() on exit) and you also avoid memory fragmentation when doing small allocations.

Precisely why I program through an abstraction layer. Changing the internals of my Mem interface class is easy and doesn't break any of my application code (which also compiles under winblows, not that I'm maintainig it much just now)...

[Karlos]

Hi Cycloid,

Nope, not conditional compilation as such. What I mean is I can just go in to my mem class and rewrite the internals. As long as I keep the same public interface to the class, nothing that uses it needs to change.

The public interface to the class is the same in the 68K, PPCWarpOS, linux and Win32 versions.

So changing the Amiga68K version's internal implementation from AllocVec() to allocVecPooled() or whatever may be an improvement but I don't have to worry about rifling through loads of application code and changing stuff.

For example, suppose my applications use Mem::alloc(), Mem::copy(), Mem::swap32() etc...example.
How class Mem works internally is not their concern, and nor should it be.
Its just your basic C++ encapsulation approach.

You can do the same thing in C too, just define a bunch of your own functions that are implementation dependent and then use them for everything else. Pretty standard really - thats all the ANSI C-library does anywayy ;-)

-edit-

Sorry I seem to have pulled this thread off topic

[Karlos]

Call me heretical but I like to hide away all the amiga stuff behind (portable) class interfaces. You won't even see so much as a ULONG in my application code... However, the fun is writing the amiga implementation, of course :-)

Nowadays, even my actual applications are classes. For example, here's the drawtest class definition that I used for the Warp3D thing...

  


class GfxTestApp : public AppBase, public Windowed {
  private:
    static char text[64];
    MilliClock timer;
    sint32 width;
    sint32 height;
    Rasterizer* gfx;
    DrawVertex* vertices;
    bool quit;
    bool flat;
    bool cull;
    bool zbuff;

    void genMesh(sint32 dx, sint32 dy);v
    void dumpPixelInfo(PixelDescriptor *pxl);
    void testMesh1();
    void testMesh2();

  protected:
    // Overridden from AppBase
    sint32 initApplication();
    sint32 runApplication();

    // Overriden from Windowed
    void keyPressNonPrintable(sint32 code);

  public:
    GfxTestApp();
    ~GfxTestApp();
};