Live data from Hacker News

Assessing the Ada Language for Audio Applications

electronicdesign.com

21–23 of 23 posts

Re: Assessing the Ada Language for Audio Applications

#21

If you're interested in using Ada, be sure to also checkout SPARK - http://www.adaic.org/advantages/spark-ada/ It's basically a more strict (in terms of safety) Ada

Ada is a language that I really want to like, but I've never been able to get enthusiastic about it.

That being said, SPARK and the affiliated tools (particularly gps (? Programming Studio?) are much nicer to use than the other formal verification tools I've tried. (Frama-C, much as I do like it, is obviously more a research project; Dafny is undocumented. I haven't tried any of the Java options.)

https://maniagnosis.crsr.net/2017/08/programming-language-sy...

Re: Assessing the Ada Language for Audio Applications

#22
post #20

Earlier quoted context omitted.

That seems like the right direction to reduce the barrier to entry for smaller development teams and consultants. Thanks for this update.

But you still need to fill out a form to get pricing!

Arguable we could say the same from IAR or WindRiver?

I would love it if all these companies were more price transparent but ultimately they are not selling in high volumes, like the likes of MSVC, so I would hazard guess they probably depend a lot more on the margins from each individual sale.

Re: Assessing the Ada Language for Audio Applications

#23

Earlier quoted context omitted.

> In my experience developing Ada software, not being able to depend on a garbage collector being present means that code intended to be used by others must manually manage memory. This means that it must manage memory exposed to client code and document who (the library or the client) is responsible for deallocation of a given data structure. Ada has controlled and limited objects, which allows implementation of sha…

My last attempt at making reuseable Ada was with Ada95. Does the current standard provide for automatic deallocation such that one need never instantiate Unchecked_Deallocation? If so, I need to revisit it. Without a garbage collector, who deallocates graphs of objects with circular references?

Hello McCulley, sorry I missed your answer.

> Does the current standard provide for automatic deallocation such that one need never instantiate Unchecked_Deallocation?

The standard provide a host of containers and pointer-like constructs that would indeed allow you to never use Unchecked_Deallocation. There's one caveat: Performance.

> Without a garbage collector, who deallocates graphs of objects with circular references?

Like in other languages where you rely on ref-counting, you need to use weak references for that. This requires a bit more explicitness from the programmer.

Post reply on HN