Comment by jmilkbal | Hacker News Reader

Comment by jmilkbal | Hacker News Reader

Parent Full thread

Ada wants to catch as much as it can before runtime. To that end, it is one strict beast when you're used to all the willy nilly (and unsafe) constructs that we can beat C into doing. Ada absolutely is harder; it's built for hard problems. I don't intend to turn away from the topic of TFA, but Ada is on quite a different plane than C for a number of reasons--reasons that I think are compelling. C is wonderful for creating a foundation for low-level software as it has demonstrated for what seems like an eternity, but beyond that--and I think the crazy things we've done over time to make it a little easier to use reflect this--something with more high-level, safe, readable, yada, yada, yada is desirable if not absolutely needed.

Dynamic allocations in Ada are a cinch by the way. We use the "new" reserved word.

subtype Hacker_News_Article_ID is Natural; -- Numbers 0 .. Integer'Last;

type Article_Handle is access all Hacker_News_Article_ID; -- "all" reserved word used allows access to variables on the stack.

Favorite_Article : aliased Hacker_New_Article_ID := 3793716; -- "aliased" so we can point to this stack variable.

Article_Pointer : Article_Handle := Favorite_Article'Access; -- A sensible default perhaps.

later on...

Article_Pointer := new Hacker_News_Article_ID (Whatever);

Good luck!

What I meant by dynamic allocation was allocating an array of the necessary size. Last I checked, the Ada solution was to always allocate the largest possible array you would ever need every time. Correct me if I'm wrong, but in Ada if two arrays are different sizes, they are completely different types.

In practice, this means your Ada written image viewer can show you 1000 thumbnails, but no more. Or 10000, or some other hard limit. And you can only view images smaller than 2MP. Unless the author made the fixed sizes really large, but now you're burning 10MB of memory per image even if they're all tiny gifs.

This is untrue. This is an Ada declaration for a fixed-size array of Foo with indices 1 to 10 (inclusive): type Foo_Array is array (Integer range 1..10) of Foo; This is an array indexed by an enumeration: type Foo_Array is array (Some_Enum) of Foo; But dynamically sized arrays can also be declared: type Foo_Array is array (Integer range <>) of Foo; Note that such an array has a dynamic lower bound and a dynamic upper bound. If I create an instance of such an array and pass it to a procedure: declare My_Array: Foo_Array (3..10) begin Do_Something (My_Array); end; then the procedure Do_Something receives both bounds of the array, 3 and 10, which it can read with the 'First and 'Last attributes.

A declaration like the one above is typically done on the stack (although it doesn't have to be). An array can be allocated on the heap with "new", with, IIRC, the following syntax: new Foo_Array (3..10)

Thanks for the clarification. Can you create an array with variable size though?

    new Foo_Array(x..y)

That's what I couldn't figure out how to do last I tried.

Yes. What you've written is exactly how to allocate an array of dynamic size on the heap. You can also do: declare My_Array: Foo_Array(X..Y); begin ... end;

Hmm, I remember it being very hard, but it seems I've lost the specifics. My bad. In any case, Ada is not a language I'm excited to work with, but Go could be one.

Reply on news.ycombinator.com