* Re: Advent of Code Day 6
@ 2020-12-06 19:37 5% ` John Perry
0 siblings, 0 replies; 12+ results
From: John Perry @ 2020-12-06 19:37 UTC (permalink / raw)
On Sunday, December 6, 2020 at 5:07:24 AM UTC-6, Jeffrey R. Carter wrote:
> On 12/6/20 9:39 AM, John Perry wrote:
> >...the only way I could find to count the number of elements in a Character_Set was by converting it to a Character_Sequence. Is there another way?
> Probably one of the set pkgs in Ada.Containers or
> PragmARC.Data_Structures.Sets.Discrete might be a better choice than Character_Set
Thanks, Ada.Containers.Hashed_Sets works fine. I look forward to initialization of containers in the next edition of gnat.
john perry
^ permalink raw reply [relevance 5%]
* use type does not seem to work for types in generic package instantiations
@ 2020-02-18 1:37 4% yoehoduv
0 siblings, 0 replies; 12+ results
From: yoehoduv @ 2020-02-18 1:37 UTC (permalink / raw)
It looks like use type has no effect when the type is from a package
declared in the same region as the use type statement.
I can make the primitive subprograms of a type directly visible with
`use all type` like this:
package Type_Package is
type T is null record;
procedure Action(X: T) is null;
end Type_Package;
with Type_Package;
procedure Use_Type is
use all type Type_Package.T;
X: Type_Package.T;
begin
Action(X);
end Use_Type;
However, it does not seem to work when I move `Type_Package` inside
`Use_Type`.
procedure Use_Type is
package Type_Package is
type T is null record;
procedure Action(X: T) is null;
end Type_Package;
use all type Type_Package.T;
X: Type_Package.T;
begin
Action(X);
end Use_Type;
I get
gcc -c use_type.adb
use_type.adb:9:04: "Action" is not visible
use_type.adb:9:04: non-visible declaration at line 4
gnatmake: "use_type.adb" compilation error
The same thing occurs when I instantiate a generic package. For
example, when I want to use the data types in `Ada.Containers`.
package Element_Set is
new Ada.Containers.Hashed_Sets(Element_Type, Hash, "=");
use all type Element_Set.Set;
The `use type` clause here seems to have no effect.
Does anyone know why?
I originally posted this at
<https://stackoverflow.com/questions/60246613/how-to-use-a-type-from-a-child-package-generic-package-instantiation>
^ permalink raw reply [relevance 4%]
* "accessibility check failed" on Node
@ 2013-06-26 23:01 3% Thomas Schmidt
0 siblings, 0 replies; 12+ results
From: Thomas Schmidt @ 2013-06-26 23:01 UTC (permalink / raw)
Hi,
I'm new to Ada. I'm trying to write some kind of neural net software.
Therefore I've written a small library to implement the neural graph.
All nodes are collected in a Hashed_Set. Neurons are specialized Nodes
of the graph. To lookup a given Neuron/Node I need the following
subprogram "findNode".
Now what I don't understand: Why does "findNode1" work well while
"findNode2" raises PROGRAM_ERROR at the line indicated below?
Given the following declarations:
-- Node of a directed graph
type Node is new NodeBase with private; -- NodeBase is tagged.
type Node_Class_Access is access all Node'Class;
and the DirectedGraph is a tagged record with one of its elements
(named "nodes") being a NodeSet defined as a Set of my NodeSets package
package NodeSets is new Ada.Containers.Hashed_Sets (
Element_Type => Node_Class_Access,
Hash => Nodes.hash,
Equivalent_Elements => Nodes.equiv);
--------------
-- findNode1 --
--------------
function findNode1
(graph : DirectedGraph;
aNode : access Node'Class)
return Node_Class_Access is
position : constant NodeSets.Cursor :=
graph.nodes.Find (Node (aNode.all)'Access); -- <<< Works well
begin
if position /= NodeSets.No_Element then
return Element (position);
else
raise NoElement;
end if;
end findNode1;
--------------
-- findNode2 --
--------------
function findNode2
(graph : DirectedGraph;
aNode : access Node'Class)
return Node_Class_Access is
position : constant NodeSets.Cursor :=
graph.nodes.Find (aNode.all'Access); -- <<< Raises
PROGRAM_ERROR with "accessibility check failed"
begin
if position /= NodeSets.No_Element then
return Element (position);
else
raise NoElement;
end if;
end findNode2;
"findNote" will be called with a Neuron as its second argument.
Many thanks for your explanations
Thomas
^ permalink raw reply [relevance 3%]
* Re: Howto declare an Ada container with access to objects of a class hierachy
@ 2013-06-13 1:46 4% ` Adam Beneschan
0 siblings, 0 replies; 12+ results
From: Adam Beneschan @ 2013-06-13 1:46 UTC (permalink / raw)
[Sorry if this is a double post. Google is being obstinate.]
On Wednesday, June 12, 2013 5:43:22 PM UTC-7, Thomas Schmidt wrote:
> Hi,
>
> Hoping this Is the right newsgroup for asking my question.
Yes, it is. Welcome.
> I want to set up a hashed set of accesses (allocated from heap) to objects
> of a given class hierarchie (the top class may f.e. be called "Top"). I
> decided to use "Ada.Containers.Indefinite_Hashed_Sets". The hash method
> should be a primitive which may be overwritten by derived classes. I've
> declared Tops hash functions formal parameter as of type "access Top". How
> do I've to declare the sets Element_Type? I think if I use "Top'Access" it
> wouldn't fit the hash functions
> parameter type nor could I store objects of classes derived from "Top".
First of all: I'm assuming that when you want a set of "accesses to
objects", you really mean that you want to work with your own accesses
(Ada's term for pointer), and you're going to allocate them yourself
with a "new" operator.
If the access will be pointing to any object in the hierarchy, then
you'd declare an access type like this:
type Top_Access is access all Top'Class;
The 'Class is needed because a Top_Access can point to any object in
the hierarchy. (In some other object-oriented languages, you
automatically get a pointer to all classes in the hierarchy and you
can't declare something that says "This is a pointer to just this one
type and *only* this one type. Ada is different.)
Now that you have an access type, you can use it as the Element_Type.
However, an *access* type is always a definite type, so you can use
Ada.Containers.Hashed_Sets instead of
Ada.Containers.Indefinite_Hashed_Sets.
To instantiate the generic, you'll need a Hash function and an
Equivalent_Elements function. You've declared a Hash function for Top
and all of the derived classes. But you need a Hash function that
takes a Top_Access as a parameter (since Element_Type will be
Top_Access). This is pretty easy to write, though:
function Hash (A : not null Top_Access) return Ada.Containers.Hash_Type is
begin
return A.all.Hash;
end Hash;
A.all is the object pointed to by A. Its type is a *classwide* type
Top'Class -- that is, it is either Top or one of its derived classes.
A.all.Hash then calls the Hash function; and since A.all's type is a
classwide type, the result is that it will call the correct Hash for
whatever the object's type is. Which is what you want.
You don't really need .all in this example; you can usually leave it
out if there's something else following.
function Hash (A : not null Top_Access) return Ada.Containers.Hash_Type is
begin
return A.Hash;
end Hash;
You'll also need something to use for Equivalent_Elements. I'm
assuming that you've written a function Equiv for Top and its derived
types that looks like
function Equiv (Left, Right : Top) return boolean;
overriding
function Equiv (Left, Right : Derived_Type_1) return boolean;
and so on. So you could try to write
function Equiv (Left, Right : not null Top_Access) return boolean is
begin
return Left.Equiv (Right.all);
end Equiv;
(You do need .all after Right here.) The problem is that this will
cause a problem if Left and Right are pointing to objects of different
types, this will raise an exception. So you'll need to check:
with Ada.Tags; --- you'll need this up at the top
function Equiv (Left, Right : not null Top_Access) return boolean is
begin
--if Ada.Tags."=" (Left.all'Tag, Right.all'Tag) -- or just
if Ada.Tags."=" (Left'Tag, Right'Tag) then
return Left.Equiv (Right.all);
else
return false;
end if;
end Equiv;
The check is kind of ugly, but I don't know of another way to test
whether two class-wide objects are the same type.
Now you can instantiate:
package Top_Set is new Ada.Containers.Hashed_Sets
(Element_Type => Top_Access,
Hash => Hash,
Equivalent_Elements => Equiv);
(If you really didn't want to use accesses, you could instantiate
Ada.Containers.Indefinite_Hashed_Sets with Element_Type => Top'Class.
You'd have to write your own Hash and Equiv functions that take a
Top'Class as parameters, and they'd look similar to the ones I showed
you above that take Top_Access as parameters. A *classwide* type is an indefinite type, so you'd need Indefinite_Hashed_Sets here.)
I realize this is a bit complicated. Hope this helps,
-- Adam
^ permalink raw reply [relevance 4%]
* Re: Ada Containers
@ 2012-10-07 21:56 5% ` Georg Bauhaus
0 siblings, 0 replies; 12+ results
From: Georg Bauhaus @ 2012-10-07 21:56 UTC (permalink / raw)
On 07.10.12 23:30, rwilco19@gmail.com wrote:
> Maby I caused some confusion earlier with a type. I misspelled the package name. It's Ada.Containers.Hash_Tables not Ada.Containers.Hashed_Tables.
>
In GNAT, package Ada.Containers.Hash_Tables
"declares the hash-table type used to implement hashed containers."
In Ada, the hashed containers are Ada.Containers.Hashed_Maps
and Ada.Containers.Hashed_Sets, and variants like Bounded_*
(new in Ada 2012) and Indefinite_*. So Hash_Tables is part of
GNAT's implementation of Ada's hashed containers, perhaps for
use by implementers only.
(You can see in the sources of GNAT's implementation of
Ada's library, this context clause in Ada.Containers.Hashed_Maps:
(private with Ada.Containers.Hash_Tables;)
^ permalink raw reply [relevance 5%]
* Re: Types, packages & objects : the good old naming conventions question (without religious ware)
@ 2009-11-02 20:36 3% ` Georg Bauhaus
0 siblings, 0 replies; 12+ results
From: Georg Bauhaus @ 2009-11-02 20:36 UTC (permalink / raw)
Stephen Leake schrieb:
> Nonsense; it is _precisely_ what I want; a list of abstract objects.
>
> You can't avoid the naming problem by changing the context!
But there should be better ways to resolve the naming problem
when changing context. Better than being unspecific, that is:
it sure is possible, if redundant, to give a hint to the
context.
> Here are the similar definitions from
> Ada.Containers.Indefinite_Doubly_Linked_Lists. I hope you won't start
> arguing that is a bad abstraction.
No, though it is perhaps notworthy that IIRC the container
type's name used to be "Container" in every package in some
earlier editions. (I couldn't resist saying some more on
names and abstract programming in another reply.)
> Note that it uses _Type for Element!
I think Element_Type was not chosen in order to take sides with
the _Type convention.
> How is that better than this:
>
> package Ada.Containers.Indefinite_Doubly_Linked_Lists is
>
> type List_Type is tagged private;
>
> generic
> with function "<" (Left, Right : Element_Type) return Boolean is <>;
> package Generic_Sorting is
>
> function Is_Sorted (List : List_Type) return Boolean;
> end Generic_Sorting;
There are fewer occurrences of "List" that need disambiguation.
But I'll happily leave it to that empirical study of the effects
of naming conventions whether other solutions work better or
worse.
>> (Rules here: Bits _of_ something, sensor _of_ something,
>> these are examples following Tom Moran's comment, if I'm
>> not mistaken. Names Sensor and Bits are really quite abstract.
>> I would force them to be used for abstract types' names, at best.)
>
> Yes, if you have a specific context and a specific meaning, then you
> should use a specific name. The corollary is that if you have a
> generic context, you should use a generic name.
But is the generic context really unspecifiable, i.e.,
do we have to become vague in our naming?
We could state, using names, or adorned names, or ...,
that something is useful in many specific cases.
This fact is a distinguishing feature.
> [List]
>
> Who said this was a linked list?
Any programmer with a Lisp background will assume List is :-)
If what matters is the set of operations needed,
then is it not possible to specify a frame of reference
for this particular meaning of "List"?
> [SAL] "list" tends to imply some access order, meaning there is at
> least First, Next, Is_Done. Containers don't have those functions.
This is where conventions can cause problems.
package Ada.Containers.Hashed_Sets is
...
function First (Container : Set) return Cursor;
SAL and Ada.Containers differ in their approaches to the same problem,
both using the same names connected to incompatible set of operations...
>> generic
>> type Less_Equal is new Ordering with private;
>> procedure Sort (Container : in out Linked_List);
>>
>> Is anything lost here?
>
> Yes! You have lost the fact that this is a generic procedure that
> doesn't care about the internal structure of the list.
OK. But then, personally, I would have though that (or the
abstract linking you have mentioned) would distinguish a List.
> You have also
> lost the ability to specify the Order at run-time.
Why? Can't I instantiate with any Ordering type from
any block that happens to be visited at run time?
> And "less_equal" implies a mathematical sort. All I really need for a
> sort that produces a linear order is "goes_before".
"Goes_Before" a better name, then. Though it corresponds to "Less"
only, not "Less_Equal", doesn't it? (I'm desparately looking
for how the [= relation is pronounced. Not_After?)
>> I think Dylan made an attempt, at least if one is satified with "car"
>> being in a different namespace than "<car>".
>
> Clearly it's a different name; it's a different lexeme. That's
> the same as the _Type convention.
I think this is significant: Many of us care about lexemes
much less than digital computers in that we rather correct
oddities like spelling errors or <framings> in letter patterns.
>> I'd still not pick essentially the same name for object Car
>> and type Car though. Even if Ada had one namespace for types
>> and one for other entities. An object is never the same
>> as a type, therefore it should be possible to distinguish
>> the difference using words.
>
> Yes! Car is distinguished from Car_Type, but List is not distinguished
> from Container. Thank you for agreeing with me :).
OK, to me, Car_Type is only minimally different from Car,
and not sufficiently. In particular, the difference carries
no meaning in either the objects domain, or in the comain
of the value sets of types.
(I guess we both would not write procedure Speed_Subprogram (...))
> Actually, I disagree with this statement; overloading types and
> objects is fine, since the language does make the distinction clear
> from context. In Dylan, I would use "car" and "<car>".
>
> It sounds like you don't like overloading in the first place. How
> about this:
>
> adding integers is never the same as adding float; it should be
> possible to distinguish the difference using words
OCaml does, though with a bit of black dirt only.
> So you don't like "+" (Left, Right : in Integer) and "+" (Left, Right
> : in Float)?
>
> If you do like operator overloading, how is that different from
> object/type overloading?
I don't like conventional operators in Ada programs,
and more so in C programs:
They create a huge set of problems when people think
they know what they are doing when writing "+".
^ permalink raw reply [relevance 3%]
* Re: OO Style with Ada Containers
2007-11-15 9:36 4% ` Ludovic Brenta
@ 2007-11-19 2:36 0% ` Matthew Heaney
1 sibling, 0 replies; 12+ results
From: Matthew Heaney @ 2007-11-19 2:36 UTC (permalink / raw)
Ludovic Brenta <ludovic@ludovic-brenta.org> writes:
Instead of this:
type Word_Counter is
Word : Ada.Strings.Unbounded.Unbounded_String;
Count : Natural;
end Word_Counter;
I would have declared it something like this:
type Word_Counter (Length : Positive) is record
Word : String (1 .. Length);
Count : Natural;
end record;
and then used the indefinite form of the (hashed) set.
> Current_Word := Get_Next_Word;
> Position := Counters.Find (Current_Word);
> if Position = Word_Counter_Hashed_Sets.No_Element then
> Counters.Insert (New_Item => (Word => Current_Word, Count => 1));
> else
> declare
> E : constant Word_Counter := Counters.Element (Position);
> begin
> Counters.Replace_Element
> (Position => Position,
> New_Item => (Word => E.Word, -- [1]
> Counter => E.Counter + 1));
> end;
> end if;
Right, but this suffers from the same problem as in the original example (Find
duplicates the work done by Insert).
> (does [1] duplicate E.Word each time we increment the counter?
Yes, because this replaces the entire element; the old element will get
destroyed, and a new element created.
> If so,
> consider using
> Ada.Containers.Hashed_Sets.Generic_Keys.Update_Element_Preserving_Keys).
Well, almost. That does indeed allow you to modify an element in-place, but it
must copy the key in order to verify that you didn't modify it, so it doesn't
really solve the problem.
^ permalink raw reply [relevance 0%]
* Re: OO Style with Ada Containers
@ 2007-11-15 11:35 4% ` Ludovic Brenta
0 siblings, 0 replies; 12+ results
From: Ludovic Brenta @ 2007-11-15 11:35 UTC (permalink / raw)
braver writes:
> Ludovic -- cool! What about the issue with the cursors operations'
> full names -- does one really have to enact `use' clauses to
> abbreviate them?
Cursor types are not tagged, therefore prefixed notation does not work
for them. It has to be "Position := [Package_Name.]Next (Position)".
But you don't need to do that at all.
Also, you seem to imply that abbreviating cursor operations is a
design goal of yours. I fail to understand why. My design goals
would rather be legibility and maintainability and I very seldom use
"use" clauses.
> Can we iterate through all elements in a collection with solely
> prefix notation?
Yes, using Ada.Containers.Hashed_Sets.Iterate. You pass an access to
a procedure to Iterate and Iterate calls your procedure once for every
element in the container, passing the cursor value.
However in the present case, I advise against iterating over any
container. My small example uses only Find, Insert, and
Replace_Element for each word in the input file; there is no iteration
over a container.
--
Ludovic Brenta.
^ permalink raw reply [relevance 4%]
* Re: OO Style with Ada Containers
@ 2007-11-15 9:36 4% ` Ludovic Brenta
2007-11-19 2:36 0% ` Matthew Heaney
0 siblings, 2 replies; 12+ results
From: Ludovic Brenta @ 2007-11-15 9:36 UTC (permalink / raw)
braver <deliverable@gmail.com> writes:
> my sample application [...] gets a Vector of tokens and inserts them
> into an Ordered_Map to count word occurrences:
I don't think you need to store all the tokens. All you need is a
Hashed_Set (which stores objects without duplication). I would do
something like
type Word_Counter is
Word : Ada.Strings.Unbounded.Unbounded_String;
Count : Natural;
end Word_Counter;
function Equivalent (L, R: Word_Counter) is
use type Ada.Strings.Unbounded.Unbounded_String;
begin
return L.Word = R.Word; -- ignore Count in the comparison
end Equivalent;
function Hash (Element : Word_Counter) is
begin
return Ada.Strings.Unbounded.Hash (Element.Word);
end Hash;
package Word_Counter_Hashed_Sets is
new Ada.Containers.Hadhed_Sets
(Element_Type => Word_Counter,
Hash => Hash,
Equivalent_Elements => Equivalent);
Counters : Word_Counter_Hashed_Sets.Set;
Current_Word : Ada.Strings.Unbounded.Unbounded_String;
Position : Word_Counter_Hashed_Sets.Cursor;
use type Word_Counter_Hashed_Sets.Cursor;
begin
...
Current_Word := Get_Next_Word;
Position := Counters.Find (Current_Word);
if Position = Word_Counter_Hashed_Sets.No_Element then
Counters.Insert (New_Item => (Word => Current_Word, Count => 1));
else
declare
E : constant Word_Counter := Counters.Element (Position);
begin
Counters.Replace_Element
(Position => Position,
New_Item => (Word => E.Word, -- [1]
Counter => E.Counter + 1));
end;
end if;
...
end;
(does [1] duplicate E.Word each time we increment the counter? If so,
consider using
Ada.Containers.Hashed_Sets.Generic_Keys.Update_Element_Preserving_Keys).
> -- would need to import "=" for private type WC.Cursor:
> -- if Ngram_Cursor = WC.No_Element
declare
use type WC.Cursor;
begin
if Ngram_Cursor = WC.No_Element then
> I'd appreciate any improvements to the above, which I deduced from ARM
HTH
--
Ludovic Brenta.
^ permalink raw reply [relevance 4%]
* Re: Generic Collection
2007-05-08 21:00 7% ` Georg Bauhaus
@ 2007-05-08 21:59 0% ` andrew
0 siblings, 0 replies; 12+ results
From: andrew @ 2007-05-08 21:59 UTC (permalink / raw)
On May 8, 4:00 pm, Georg Bauhaus <rm.tsoh+bauh...@maps.futureapps.de>
wrote:
> On Tue, 2007-05-08 at 12:29 -0700, andrew wrote:
> > I cannot say for sure if the "is a" relations aren't entirely
> > artificial. It seems to me it would work either way. The difference
> > for me is that I cannot visualize the composition you mentioned.
>
> As you noted, I meant that "a tuple is a collection of attributes"
> doesn't necessarily imply inheritance relationship; TUPLE doesn't have
> to inherit from a type COLLECTION_OF_ATTRIBUTES.
>
> I think there are various possibilities; RDB2 (below RDB) shows
> types that have components of other types (that is, are composed :-)
> but are otherwise unrelated.
> Package RDB desclares "is a" relations in the sense you describe
> by making the DB types be "a collection of" objects of "smaller"
> types.
>
> > So what you are saying is that the type Item in my example is the
> > parameter you are talking about?
>
> Erh, I guess so.
>
> with Ada.Containers.Hashed_Sets;
> with Data;
>
> package RDB is
>
> use Ada;
>
> type DP is access Data.T'class;
> function compare(a, b: DP) return BOOLEAN;
> function hash(element: DP) return Containers.HASH_TYPE;
>
> subtype ATTRIBUTE is DP;
>
> package Attributes is new Containers.Hashed_Sets
> (ELEMENT_TYPE => ATTRIBUTE,
> hash => hash,
> equivalent_elements => compare);
>
> subtype TUPLE is Attributes.SET;
> function hash(element: TUPLE) return Containers.HASH_TYPE;
>
> package Tuples is new Containers.Hashed_Sets
> (ELEMENT_TYPE => TUPLE,
> hash => hash,
> equivalent_elements => Attributes."=",
> "=" => Attributes."=");
>
> subtype TABLE is Tuples.SET;
> function hash(element: TABLE) return Containers.HASH_TYPE;
>
> package Tables is new Containers.Hashed_Sets
> (ELEMENT_TYPE => TABLE,
> Hash => hash,
> equivalent_elements => Tuples."=",
> "=" => Tuples."=");
>
> -- ...
>
> end RDB;
>
> with Ada.Containers.Hashed_Sets;
> with Data;
>
> package RDB2 is
>
> use Ada;
>
> type DP is access Data.T'class;
> function compare(a, b: DP) return BOOLEAN;
> function hash(element: DP) return Containers.HASH_TYPE;
>
> subtype ATTRIBUTE is DP;
>
> package Attributes is new Containers.Hashed_Sets
> (ELEMENT_TYPE => ATTRIBUTE,
> hash => hash,
> equivalent_elements => compare);
>
> type TUPLE is
> record
> -- ...
> columns: Attributes.SET;
> end record;
> function compare(a, b: TUPLE) return BOOLEAN;
> function hash(element: TUPLE) return Containers.HASH_TYPE;
>
> package Tuples is new Containers.Hashed_Sets
> (ELEMENT_TYPE => TUPLE,
> hash => hash,
> equivalent_elements => compare);
>
> type TABLE is
> record
> -- ...
> rows: Tuples.SET;
> end record;
> function compare(a, b: TABLE) return BOOLEAN;
> function hash(element: TABLE) return Containers.HASH_TYPE;
>
> package Tables is new Containers.Hashed_Sets
> (ELEMENT_TYPE => TABLE,
> Hash => hash,
> equivalent_elements => compare);
>
> type SCHEMA is
> record
> -- ...
> relations: Tables.SET;
> end record;
>
> end RDB2;
RDB2 looks good to me and is pretty close to what I had in mind.
I think I finally get what you were saying about inheritance. Before
I posted the topic I was thinking about the design and I just wrote
down the "table is a collection" as part of sentence. In my mind I
was thinking of a variable declaration:
table: collection;
tuple: collection;
schema: collection;
and so I posted my question.
^ permalink raw reply [relevance 0%]
* Re: Generic Collection
@ 2007-05-08 21:00 7% ` Georg Bauhaus
2007-05-08 21:59 0% ` andrew
0 siblings, 1 reply; 12+ results
From: Georg Bauhaus @ 2007-05-08 21:00 UTC (permalink / raw)
On Tue, 2007-05-08 at 12:29 -0700, andrew wrote:
> I cannot say for sure if the "is a" relations aren't entirely
> artificial. It seems to me it would work either way. The difference
> for me is that I cannot visualize the composition you mentioned.
As you noted, I meant that "a tuple is a collection of attributes"
doesn't necessarily imply inheritance relationship; TUPLE doesn't have
to inherit from a type COLLECTION_OF_ATTRIBUTES.
I think there are various possibilities; RDB2 (below RDB) shows
types that have components of other types (that is, are composed :-)
but are otherwise unrelated.
Package RDB desclares "is a" relations in the sense you describe
by making the DB types be "a collection of" objects of "smaller"
types.
> So what you are saying is that the type Item in my example is the
> parameter you are talking about?
Erh, I guess so.
with Ada.Containers.Hashed_Sets;
with Data;
package RDB is
use Ada;
type DP is access Data.T'class;
function compare(a, b: DP) return BOOLEAN;
function hash(element: DP) return Containers.HASH_TYPE;
subtype ATTRIBUTE is DP;
package Attributes is new Containers.Hashed_Sets
(ELEMENT_TYPE => ATTRIBUTE,
hash => hash,
equivalent_elements => compare);
subtype TUPLE is Attributes.SET;
function hash(element: TUPLE) return Containers.HASH_TYPE;
package Tuples is new Containers.Hashed_Sets
(ELEMENT_TYPE => TUPLE,
hash => hash,
equivalent_elements => Attributes."=",
"=" => Attributes."=");
subtype TABLE is Tuples.SET;
function hash(element: TABLE) return Containers.HASH_TYPE;
package Tables is new Containers.Hashed_Sets
(ELEMENT_TYPE => TABLE,
Hash => hash,
equivalent_elements => Tuples."=",
"=" => Tuples."=");
-- ...
end RDB;
with Ada.Containers.Hashed_Sets;
with Data;
package RDB2 is
use Ada;
type DP is access Data.T'class;
function compare(a, b: DP) return BOOLEAN;
function hash(element: DP) return Containers.HASH_TYPE;
subtype ATTRIBUTE is DP;
package Attributes is new Containers.Hashed_Sets
(ELEMENT_TYPE => ATTRIBUTE,
hash => hash,
equivalent_elements => compare);
type TUPLE is
record
-- ...
columns: Attributes.SET;
end record;
function compare(a, b: TUPLE) return BOOLEAN;
function hash(element: TUPLE) return Containers.HASH_TYPE;
package Tuples is new Containers.Hashed_Sets
(ELEMENT_TYPE => TUPLE,
hash => hash,
equivalent_elements => compare);
type TABLE is
record
-- ...
rows: Tuples.SET;
end record;
function compare(a, b: TABLE) return BOOLEAN;
function hash(element: TABLE) return Containers.HASH_TYPE;
package Tables is new Containers.Hashed_Sets
(ELEMENT_TYPE => TABLE,
Hash => hash,
equivalent_elements => compare);
type SCHEMA is
record
-- ...
relations: Tables.SET;
end record;
end RDB2;
^ permalink raw reply [relevance 7%]
* Re: Hash table
@ 2005-08-13 23:58 4% ` Matthew Heaney
0 siblings, 0 replies; 12+ results
From: Matthew Heaney @ 2005-08-13 23:58 UTC (permalink / raw)
David Trudgett <wpower@zeta.org.au.nospamplease> writes:
> I'm looking for a Free Software Ada95 container library, or in
> particular, a hash table (or associative list).
Ada 2005 will have both sets and maps. You're asking specifically for a
hashed version, but keep in mind that an ordered container (having an
identical interface, but different time complexity) might satisfy your
needs just as well.
The hashed containers are:
ada.containers.hashed_sets
ada.containers.indefinite_hashed_sets
ada.containers.hashed_maps
ada.containers.indefinite_hashed_maps
The ordered forms are:
ada.containers.ordered_sets
ada.containers.indefinite_ordered_sets
ada.containers.ordered_maps
ada.containers.indefinite_ordered_maps
> I noticed that Ada 2005 may include a standard Ada.Containers library,
> but is there a working prototype of this available now?
Yes, there's a public reference implementation available here:
http://charles.tigris.org/
Follow the links to the CVS repository, to the ai302 subdirectory. The
names use gnat run-time syntax, so you're looking for:
a-cohama.ad[sb]
a-cihama.ad[sb]
a-cohase.ad[sb]
a-cihase.ad[sb]
Note that these will only compile with an Ada 2005 compiler. If you're
using the latest version of gnat, use the -gnat05 switch to compile them.
If you don't have an Ada 2005 compiler, then you can modify the sources
to your liking. That will mean replacing an anonymous access subprogram
parameters with something else, typically a generic operation that
passes the subprogram as a generic formal. For example, the procedure:
procedure Iterate
(Container : in Map;
Process : not null access procedure (Position : Cursor));
should be re-written as:
generic
with procedure Process (Position : Cursor);
procedure Generic_Iteration (Container : in Map);
(Note that replacing the anonymous access subprogram parameters with
named access parameters is probably not what you want, because of the
accessibility rules. Hence the generic declaration above.)
> A bit of searching found the ASL (Ada Structured Library --
> http://sourceforge.net/projects/adasl), which hasn't had a new release
> since 2001 (which means it must be perfect ;-)). Should I use ASL, and
> if I do, will it be completely different from the proposed
> Ada.Containers standard?
I would try to use a reference implementation of the standard library,
modified as necessary to run under pure Ada 95. I can help you make the
necessary modifications.
In general, we prefer that users use the standard library now, since
that helps us find bugs in the design of the library (early adopters
have been extremely helpful here), and in the actual implementation of
the library.
> I'm using Gnat (3.15p) on Debian Linux.
Do you have access to gcc 4.x? The standard container library is
already bundled with the gcc 4 release.
-Matt
^ permalink raw reply [relevance 4%]
Results 1-12 of 12 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2005-08-13 0:43 Hash table David Trudgett
2005-08-13 23:58 4% ` Matthew Heaney
2007-05-08 19:29 Generic Collection andrew
2007-05-08 21:00 7% ` Georg Bauhaus
2007-05-08 21:59 0% ` andrew
2007-11-14 23:28 OO Style with Ada Containers braver
2007-11-14 23:50 ` Adam Beneschan
2007-11-14 23:59 ` braver
2007-11-15 0:24 ` braver
2007-11-15 9:36 4% ` Ludovic Brenta
2007-11-15 10:36 ` braver
2007-11-15 11:35 4% ` Ludovic Brenta
2007-11-19 2:36 0% ` Matthew Heaney
2009-10-29 17:11 Types, packages & objects : the good old naming conventions question (without religious ware) Hibou57 (Yannick Duchêne)
2009-10-29 18:11 ` Georg Bauhaus
2009-10-30 10:52 ` Stephen Leake
2009-10-30 13:40 ` Georg Bauhaus
2009-10-31 11:58 ` Stephen Leake
2009-11-02 20:36 3% ` Georg Bauhaus
2012-10-07 19:58 Ada Containers rwilco19
2012-10-07 20:40 ` Maciej Sobczak
2012-10-07 21:30 ` rwilco19
2012-10-07 21:56 5% ` Georg Bauhaus
2013-06-13 0:43 Howto declare an Ada container with access to objects of a class hierachy Thomas Schmidt
2013-06-13 1:46 4% ` Adam Beneschan
2013-06-26 23:01 3% "accessibility check failed" on Node Thomas Schmidt
2020-02-18 1:37 4% use type does not seem to work for types in generic package instantiations yoehoduv
2020-12-06 8:39 Advent of Code Day 6 John Perry
2020-12-06 11:07 ` Jeffrey R. Carter
2020-12-06 19:37 5% ` John Perry
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox