[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug #62147] Expanded classes not printable
From: |
Paolo Redælli |
Subject: |
Re: [bug #62147] Expanded classes not printable |
Date: |
Mon, 7 Mar 2022 16:27:44 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.0 |
I'm quite puzzled by this issue so I think it is better to discuss it in
the mailinst list.
See the recently committed test/language/expanded/test_expanded42.e
class TEST_EXPANDED42 -- Try to print an ARRAY of expanded values
insert EIFFELTEST_TOOLS redefine default_create end
create {ANY} default_create -- make
feature {ANY}
default_create
local foo, bar: AUX_EXPANDED40_EXP -- an empty expanded class
do
(<< foo, bar >> ).print_on(io)
io.put_new_line
end
end -- class TEST_EXP_ARRAY
expanded class AUX_EXPANDED40_EXP
-- empty class
end -- class AUX_EXPANDED40_EXP
It triggers a compile error in ANY, specifically in
out_in_tagged_out_memory
-- Append terse printable representation of current object in
`tagged_out_memory'.
require
locked: tagged_out_locked
local
like_current: like Current
do
tagged_out_memory.append(generating_type)
>>>>>HERE if like_current = Void then
-- Not an expanded type:
tagged_out_memory.extend('#')
to_pointer.append_in(tagged_out_memory)
end
tagged_out_memory.extend('[')
fill_tagged_out_memory
tagged_out_memory.extend(']')
end
because an expanded class could never be compared to Void, which is the
default reference (aka NULL for people accostumed to C). That piece of
code prints the address (pointer) of the object.
The compiler is right - Void does not conform to any expanded object
which are compared by value and not by reference.
I see three scenario:
1) we remove the feature altogether from ANY.
2) we keep it for reference objects but then ANY should have some
external "built_in" features such as is_reference:BOOLEAN and
is_expanded: BOOLEAN
3) we want to print the address of each and every object, even expanded
one, so there must be a a function in the runtime but I fear it will be
far from simple to implement.
I was going to naïvely follow scenario 1, but then I recalled that some
people may rely on the output of the address...
To be truly earnest I thought that this issue is the remnant of some
silly commit of mine, but as far as I can say it has been like this at
least since adler-rc1 release (2009).
I wonder how such a issue has never been encountered before. It seems
that people do not print expanded classes.
Il 07/03/22 11:55, Paolo Redaelli ha scritto:
URL:
<https://savannah.gnu.org/bugs/?62147>
Summary: Expanded classes not printable
Project: Liberty Eiffel
Submitted by: Tybor
Submitted on: Mon 07 Mar 2022 10:55:49 AM UTC
Category: Kernel libraries
Severity: 4 - Important
Priority: 5 - Normal
Status: Need Info
Assigned to: None
Open/Closed: Open
Release: None
Discussion Lock: Any
Fixed Release: None
Planned Release: None
_______________________________________________________
Details:
Let's have an
expanded class FOO
-- empty
end
Any try to print it out, either in a collection (an ARRAY) or stand alone
strigger a compile time error such as:
****** Error: Invalid usage of feature `to_pointer' of class ANY. (The target
which is of type AUX_EXPANDED40_EXP cannot be converted to a memory address.)
The source lines relevant to this message are the following:
Line 284 column 13 in ANY
(/home/paolo/src/liberty-eiffel/src/lib/kernel/any.e):
to_pointer.append_in(tagged_out_memory)
^
Line 421 column 4 in ANY
(/home/paolo/src/liberty-eiffel/src/lib/kernel/any.e):
to_pointer: POINTER
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?62147>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
- Re: [bug #62147] Expanded classes not printable,
Paolo Redælli <=