* Ada.Directories.Base_Name and dot files
@ 2009-10-07 12:40
2009-10-07 14:46 ` Yannick Duchêne Hibou57
` (3 more replies)
0 siblings, 4 replies; 17+ messages in thread
From: @ 2009-10-07 12:40 UTC (permalink / raw)
Hey all,
While working my way through the excellent Ada.Directories package, I've
stumbled on a minor annoyance: The Base_Name function does not handle
dot files very gracefully.
Here's an example:
++++
with Ada.Text_IO;
with Ada.Directories;
procedure Dot is
package IO renames Ada.Text_IO;
package D renames Ada.Directories;
begin
IO.Put_Line (Item => "1: " & D.Base_Name (Name => "foo.txt"));
IO.Put_Line (Item => "2: " & D.Base_Name (Name => ".foo"));
IO.Put_Line (Item => "3: " & D.Base_Name (Name => ".foo.bar"));
end Dot;
++++
The output I get is this:
++++
1: foo
2:
3: .foo
++++
What I had hoped for, was this:
++++
1: foo
2: .foo
3: .foo
++++
With the current null string solution, you'd have to do some manual
parsing to get to the actual basename of a dot file.
Instead of returning a null string when the first character is a dot,
couldn't Base_Name just as well just return the basename *with* the dot,
because that is the actual basename for a dot file. The dot is part of
the name.
Is there a good reason for the current behavior?
There's a comment in the body of Base_Name:
++++
-- Look for the last dot in the file name and return the part of the
-- file name preceding this last dot. If the first dot is the first
-- character of the file name, the base name is the empty string.
++++
So it's not like the programmers behind this wasn't aware of dot files,
they've just opted for a somewhat odd solution, in my humble, and not
very expert, opinion. :o)
--
Regards,
Thomas L�cke
Email: tl at ada-dk.org
Web: http:ada-dk.org
IRC nick: ThomasLocke
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Ada.Directories.Base_Name and dot files
2009-10-07 12:40 Ada.Directories.Base_Name and dot files
@ 2009-10-07 14:46 ` Yannick Duchêne Hibou57
2009-10-07 17:06 `
2009-10-07 14:52 ` Adam Beneschan
` (2 subsequent siblings)
3 siblings, 1 reply; 17+ messages in thread
From: Yannick Duchêne Hibou57 @ 2009-10-07 14:46 UTC (permalink / raw)
Hi Thomas,
There was somewhat similar discuss some times ago :
http://groups.google.com/group/comp.lang.ada/browse_thread/thread/31af760e939556ef?hl=fr#
It seems that your Ada implementation (the behavior is left as
implementation defined in some areas) defines base file name as
everything before the last dot (and the extension is then every thing
after the last dot).
This is something with which I fully agree.
But what about (another question) a full file name like “ my-
page.fr.html ” ? What is the base name ? Can you guess ?
Well, the UNIX basename command will give you something, the Windows
OS will tell you it is “ my-page.fr ” and a web server (not its host
OS) may tell you it is “ my-page ”, because with some convention, fr
and html are both extensions and separated unordered extensions (ex. “
my-page.html.fr ” would be interpreted as the same as“ my-page.fr.html
”). You see how it may be legitimately variable depending on
legitimate conventions ?
Did you run your tests on Windows ? I suppose most of Ada
implementation defined behavior are inspired from that of the host OS
(possibly).
I would like to say : when in any particular area, you need a
particular specification which is not of concerns with the
fundamentals of the language design, don't hesitate to design your own
dedicated package.
You have some strong requirements about what the interpretation of
file names should, and probably can't expect Ada always agree with
this kind of level of details : the best is to design your own
interpretation function.
You known, it appears that a lot of peoples do that (especially with
files by the way), and Ada designed programs are far from only made up
of Ada's standard packages
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Ada.Directories.Base_Name and dot files
2009-10-07 12:40 Ada.Directories.Base_Name and dot files
2009-10-07 14:46 ` Yannick Duchêne Hibou57
@ 2009-10-07 14:52 ` Adam Beneschan
2009-10-07 17:06 `
2009-10-07 15:10 ` Adam Beneschan
2009-10-08 9:39 ` Stephen Leake
3 siblings, 1 reply; 17+ messages in thread
From: Adam Beneschan @ 2009-10-07 14:52 UTC (permalink / raw)
On Oct 7, 5:40 am, Thomas Løcke <"tl at ada-dk.org"> wrote:
> Hey all,
>
> While working my way through the excellent Ada.Directories package, I've
> stumbled on a minor annoyance: The Base_Name function does not handle
> dot files very gracefully.
>
> Here's an example:
>
> ++++
> with Ada.Text_IO;
> with Ada.Directories;
>
> procedure Dot is
> package IO renames Ada.Text_IO;
> package D renames Ada.Directories;
>
> begin
> IO.Put_Line (Item => "1: " & D.Base_Name (Name => "foo.txt"));
> IO.Put_Line (Item => "2: " & D.Base_Name (Name => ".foo"));
> IO.Put_Line (Item => "3: " & D.Base_Name (Name => ".foo.bar"));
> end Dot;
> ++++
>
> The output I get is this:
>
> ++++
> 1: foo
> 2:
> 3: .foo
> ++++
>
> What I had hoped for, was this:
>
> ++++
> 1: foo
> 2: .foo
> 3: .foo
> ++++
>
> With the current null string solution, you'd have to do some manual
> parsing to get to the actual basename of a dot file.
>
> Instead of returning a null string when the first character is a dot,
> couldn't Base_Name just as well just return the basename *with* the dot,
> because that is the actual basename for a dot file. The dot is part of
> the name.
>
> Is there a good reason for the current behavior?
>
> There's a comment in the body of Base_Name:
>
> ++++
> -- Look for the last dot in the file name and return the part of the
> -- file name preceding this last dot. If the first dot is the first
> -- character of the file name, the base name is the empty string.
> ++++
>
> So it's not like the programmers behind this wasn't aware of dot files,
> they've just opted for a somewhat odd solution, in my humble, and not
> very expert, opinion. :o)
I'm assuming you're using Linux or some other Unix-type system?
Although the exact meanings of the Ada.Directories operations are
implementation-dependent, the AARM gives the "expected interpretation"
on Unix-type and Windows systems. (AARM A.16(1.a)) AARM A.16(80.a)
says, 'For Unix and Windows®, the base name is the portion of the
simple name preceding the rightmost period (except for the special
directory names "." and "..", whose Base_Name is "." and "..").'
Unlike VAX/VMS, where every file has a definite, separate "base" and
"extension" name (the extension name can be blank), Unix is a lot
looser (and Windows is a little bit looser). RM A.16(78) says, "The
extension name is a portion of a simple name (not including any
separator characters), typically used to identify the file class." On
Unix, this is only the case sometimes. For source files, it's often
true, and also for other files like .o (object) files. But it's not
consistent. Executable files don't have an extension. Files
beginning with a dot are usually "hidden" files with some control
information, and I wouldn't expect them to fall into the "basename-dot-
extension" pattern that other file names fall into. When I make a
backup copy of a file, I'll often just append .save to the file name,
but I wouldn't consider ".save" to be an extension, and it certainly
doesn't identify the file class. But I wouldn't expect an application
to read my mind and know that.
So the Base_Name and Extension functions aren't going to be
appropriate for every file name on Unix, since not all Unix files have
definite base names and extensions. Bottom line: if you know what you
want, just use the string functions and do it yourself.
-- Adam
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Ada.Directories.Base_Name and dot files
2009-10-07 12:40 Ada.Directories.Base_Name and dot files
2009-10-07 14:46 ` Yannick Duchêne Hibou57
2009-10-07 14:52 ` Adam Beneschan
@ 2009-10-07 15:10 ` Adam Beneschan
2009-10-07 15:37 ` Yannick Duchêne Hibou57
2009-10-07 20:11 `
2009-10-08 9:39 ` Stephen Leake
3 siblings, 2 replies; 17+ messages in thread
From: Adam Beneschan @ 2009-10-07 15:10 UTC (permalink / raw)
On Oct 7, 5:40 am, Thomas Løcke <"tl at ada-dk.org"> wrote:
> Hey all,
>
> While working my way through the excellent Ada.Directories package, I've
> stumbled on a minor annoyance: The Base_Name function does not handle
> dot files very gracefully.
>
> Here's an example:
>
> ++++
> with Ada.Text_IO;
> with Ada.Directories;
>
> procedure Dot is
> package IO renames Ada.Text_IO;
> package D renames Ada.Directories;
>
> begin
> IO.Put_Line (Item => "1: " & D.Base_Name (Name => "foo.txt"));
> IO.Put_Line (Item => "2: " & D.Base_Name (Name => ".foo"));
> IO.Put_Line (Item => "3: " & D.Base_Name (Name => ".foo.bar"));
> end Dot;
> ++++
>
> The output I get is this:
>
> ++++
> 1: foo
> 2:
> 3: .foo
> ++++
>
> What I had hoped for, was this:
>
> ++++
> 1: foo
> 2: .foo
> 3: .foo
> ++++
>
> With the current null string solution, you'd have to do some manual
> parsing to get to the actual basename of a dot file.
>
> Instead of returning a null string when the first character is a dot,
> couldn't Base_Name just as well just return the basename *with* the dot,
> because that is the actual basename for a dot file. The dot is part of
> the name.
>
> Is there a good reason for the current behavior?
>
> There's a comment in the body of Base_Name:
>
> ++++
> -- Look for the last dot in the file name and return the part of the
> -- file name preceding this last dot. If the first dot is the first
> -- character of the file name, the base name is the empty string.
> ++++
>
> So it's not like the programmers behind this wasn't aware of dot files,
> they've just opted for a somewhat odd solution, in my humble, and not
> very expert, opinion. :o)
P.S. For more information, look at the discussion of AI95-248
(http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ais/ai-00248.txt?rev=1.32)
starting at around November 21, 2003 (and a few earlier entries from
July of that year). There was some discussion of what the best
behavior would be with regard to file names like that. It was pointed
out that on Windows, a file named ".abc" is treated as any other file
with an extension of .abc---if you open it in Explorer, Windows uses
the "abc" to determine what application to try to open it with. There
was also some feeling that the rules should be the same on Windows and
Unix, and some feeling that these are marginal cases we shouldn't
worry about, and some feeling that the Base_Name and Extension
functions shouldn't have been there at all. The resulting solution is
a compromise. My feeling is still that this is a somewhat "marginal"
case---i.e. many Unix file names don't fall into the base-name/
extension paradigm and it's not sensible to talk about base names or
extensions of such files, so therefore using Base_Name or Extension on
them is likely not to do what you'd expect.
-- Adam
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Ada.Directories.Base_Name and dot files
2009-10-07 15:10 ` Adam Beneschan
@ 2009-10-07 15:37 ` Yannick Duchêne Hibou57
2009-10-11 2:39 ` Randy Brukardt
2009-10-07 20:11 `
1 sibling, 1 reply; 17+ messages in thread
From: Yannick Duchêne Hibou57 @ 2009-10-07 15:37 UTC (permalink / raw)
On 7 oct, 17:10, Adam Beneschan <a...@irvine.com> wrote:
> It was pointed
> out that on Windows, a file named ".abc" is treated as any other file
> with an extension of .abc
That's a bit less clear on Windows
Windows XP accept the file names as valid on its file system, but the
Explorer does not allow to create such file names, complaining it is
an invalid file name. But it is still able to access it.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Ada.Directories.Base_Name and dot files
2009-10-07 14:52 ` Adam Beneschan
@ 2009-10-07 17:06 `
0 siblings, 0 replies; 17+ messages in thread
From: @ 2009-10-07 17:06 UTC (permalink / raw)
Adam Beneschan wrote:
> I'm assuming you're using Linux or some other Unix-type system?
Yes, Slackware Linux.
> Although the exact meanings of the Ada.Directories operations are
> implementation-dependent, the AARM gives the "expected interpretation"
> on Unix-type and Windows systems. (AARM A.16(1.a)) AARM A.16(80.a)
> says, 'For Unix and Windows�, the base name is the portion of the
> simple name preceding the rightmost period (except for the special
> directory names "." and "..", whose Base_Name is "." and "..").'
Yes, I understand that and it's that exact design decision that made me
wonder.
If the first character of a file name is a period, why is it then better
to return a null string as the base name, instead of, for example, the
period plus any characters following the period, up until the last
period, ie. ".secret" would yield ".secret" as the base name and
".secret.conf.save" would yield ".secret.conf"
So I understand what it is doing, I just don't understand why. The null
string design baffles me.
While writing this, I can though see that the null string sends a pretty
clear signal to the programmer: This file is not "normal". You should
probably take a close look at it, and figure out what you want. I guess
that's actually a pretty good thing. Except on some systems a dot file
might be completely normal.
Hehe, there's just no winning here! :D
> Unlike VAX/VMS, where every file has a definite, separate "base" and
> "extension" name (the extension name can be blank), Unix is a lot
> looser (and Windows is a little bit looser). RM A.16(78) says, "The
> extension name is a portion of a simple name (not including any
> separator characters), typically used to identify the file class." On
> Unix, this is only the case sometimes. For source files, it's often
> true, and also for other files like .o (object) files. But it's not
> consistent. Executable files don't have an extension. Files
> beginning with a dot are usually "hidden" files with some control
> information, and I wouldn't expect them to fall into the "basename-dot-
> extension" pattern that other file names fall into. When I make a
> backup copy of a file, I'll often just append .save to the file name,
> but I wouldn't consider ".save" to be an extension, and it certainly
> doesn't identify the file class. But I wouldn't expect an application
> to read my mind and know that.
Gotcha!
> So the Base_Name and Extension functions aren't going to be
> appropriate for every file name on Unix, since not all Unix files have
> definite base names and extensions. Bottom line: if you know what you
> want, just use the string functions and do it yourself.
>
> -- Adam
Yes, that was also my first thought: Some manual parsing is necessary
for "special" cases.
Thank you for your reply Adam. :o)
--
Regards,
Thomas L�cke
Email: tl at ada-dk.org
Web: http:ada-dk.org
IRC nick: ThomasLocke
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Ada.Directories.Base_Name and dot files
2009-10-07 14:46 ` Yannick Duchêne Hibou57
@ 2009-10-07 17:06 `
0 siblings, 0 replies; 17+ messages in thread
From: @ 2009-10-07 17:06 UTC (permalink / raw)
Yannick Duch�ne Hibou57 wrote:
> Hi Thomas,
>
> There was somewhat similar discuss some times ago :
> http://groups.google.com/group/comp.lang.ada/browse_thread/thread/31af760e939556ef?hl=fr#
Very interesting thread. Thank you.
> It seems that your Ada implementation (the behavior is left as
> implementation defined in some areas) defines base file name as
> everything before the last dot (and the extension is then every thing
> after the last dot).
>
> This is something with which I fully agree.
I guess I had expected a Linux implementation of Ada 2005 to exhibit a
"proper" understanding of the Unix way of handling files, dot files
included.
> But what about (another question) a full file name like � my-
> page.fr.html � ? What is the base name ? Can you guess ?
>
> Well, the UNIX basename command will give you something, the Windows
> OS will tell you it is � my-page.fr � and a web server (not its host
> OS) may tell you it is � my-page �, because with some convention, fr
> and html are both extensions and separated unordered extensions (ex. �
> my-page.html.fr � would be interpreted as the same as� my-page.fr.html
> �). You see how it may be legitimately variable depending on
> legitimate conventions ?
Yes, I understand that.
> Did you run your tests on Windows ? I suppose most of Ada
> implementation defined behavior are inspired from that of the host OS
> (possibly).
I did not run any tests on Windows. I use Windows for gaming, and
nothing else. :o)
> I would like to say : when in any particular area, you need a
> particular specification which is not of concerns with the
> fundamentals of the language design, don't hesitate to design your own
> dedicated package.
>
> You have some strong requirements about what the interpretation of
> file names should, and probably can't expect Ada always agree with
> this kind of level of details : the best is to design your own
> interpretation function.
>
> You known, it appears that a lot of peoples do that (especially with
> files by the way), and Ada designed programs are far from only made up
> of Ada's standard packages
Yes, as I expected. Some home-grown parsing to assist Ada.Directories
when special cases occur.
I can live with that.
I guess it just confused me that my GNAT GPL Linux environment was not
able to handle something as "simple" (note the quotes!) as dot files.
Thank you for your insightful post.
--
Regards,
Thomas L�cke
Email: tl at ada-dk.org
Web: http:ada-dk.org
IRC nick: ThomasLocke
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Ada.Directories.Base_Name and dot files
2009-10-07 15:10 ` Adam Beneschan
2009-10-07 15:37 ` Yannick Duchêne Hibou57
@ 2009-10-07 20:11 `
1 sibling, 0 replies; 17+ messages in thread
From: @ 2009-10-07 20:11 UTC (permalink / raw)
Adam Beneschan wrote:
> P.S. For more information, look at the discussion of AI95-248
> (http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ais/ai-00248.txt?rev=1.32)
> starting at around November 21, 2003 (and a few earlier entries from
> July of that year).
Nice link!
Thanks a lot Adam. Very interesting reading indeed.
--
Regards,
Thomas L�cke
Email: tl at ada-dk.org
Web: http:ada-dk.org
IRC nick: ThomasLocke
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Ada.Directories.Base_Name and dot files
2009-10-07 12:40 Ada.Directories.Base_Name and dot files
` (2 preceding siblings ...)
2009-10-07 15:10 ` Adam Beneschan
@ 2009-10-08 9:39 ` Stephen Leake
2009-10-08 9:58 `
3 siblings, 1 reply; 17+ messages in thread
From: Stephen Leake @ 2009-10-08 9:39 UTC (permalink / raw)
Thomas L�cke <"tl at ada-dk.org"> writes:
> begin
> IO.Put_Line (Item => "1: " & D.Base_Name (Name => "foo.txt"));
> IO.Put_Line (Item => "2: " & D.Base_Name (Name => ".foo"));
> IO.Put_Line (Item => "3: " & D.Base_Name (Name => ".foo.bar"));
> end Dot;
> ++++
>
> The output I get is this:
>
> ++++
> 1: foo
> 2:
> 3: .foo
> ++++
>
> What I had hoped for, was this:
>
> ++++
> 1: foo
> 2: .foo
> 3: .foo
> ++++
Just out of curiosity, what made you hope for this? The Gnu coreutils
basename function doesn't do what you want, either:
$ basename foo.txt
foo.txt
$ basename foo.txt .txt
foo
$ basename .foo
.foo
$ basename .foo .foo
.foo
$ basename .foo.bar
.foo.bar
$ basename .foo.bar .bar
.foo
$ basename .foo.bar .foo
.foo.bar
$ basename .foo.bar .foo.bar
.foo.bar
> With the current null string solution, you'd have to do some manual
> parsing to get to the actual basename of a dot file.
What is your definition of "the actual basename"?
> Is there a good reason for the current behavior?
It's well-defined. And it does what I want :).
--
-- Stephe
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Ada.Directories.Base_Name and dot files
2009-10-08 9:39 ` Stephen Leake
@ 2009-10-08 9:58 `
2009-10-26 19:26 ` Type casting Bruno
2009-10-26 19:27 ` Conversions Bruno
0 siblings, 2 replies; 17+ messages in thread
From: @ 2009-10-08 9:58 UTC (permalink / raw)
Stephen Leake wrote:
> Thomas L�cke <"tl at ada-dk.org"> writes:
>
>> begin
>> IO.Put_Line (Item => "1: " & D.Base_Name (Name => "foo.txt"));
>> IO.Put_Line (Item => "2: " & D.Base_Name (Name => ".foo"));
>> IO.Put_Line (Item => "3: " & D.Base_Name (Name => ".foo.bar"));
>> end Dot;
>> ++++
>>
>> The output I get is this:
>>
>> ++++
>> 1: foo
>> 2:
>> 3: .foo
>> ++++
>>
>> What I had hoped for, was this:
>>
>> ++++
>> 1: foo
>> 2: .foo
>> 3: .foo
>> ++++
>
> Just out of curiosity, what made you hope for this? The Gnu coreutils
> basename function doesn't do what you want, either:
Yes, that was actually a typo. I was hoping for the same behavior as
basename, as shown in your output below.
In my haste, I just forgot to add the .bar part to output line 3: .foo
I was too focused on the second line, where .foo was completely
eliminated.
>
> $ basename foo.txt
> foo.txt
> $ basename foo.txt .txt
> foo
> $ basename .foo
> .foo
> $ basename .foo .foo
> .foo
> $ basename .foo.bar
> .foo.bar
> $ basename .foo.bar .bar
> .foo
> $ basename .foo.bar .foo
> .foo.bar
> $ basename .foo.bar .foo.bar
> .foo.bar
>
>
>> With the current null string solution, you'd have to do some manual
>> parsing to get to the actual basename of a dot file.
>
> What is your definition of "the actual basename"?
On my Linux system, my definition of the basename, is the name returned
by basename.
>
>> Is there a good reason for the current behavior?
>
> It's well-defined. And it does what I want :).
>
I've read the link posted by Adam, and it has made me a lot wiser in
regards to this issue. I feel I now have a better understanding of why
Ada.Directories.Base_Name does what it does.
So I guess I now also think that it is both well-defined and that it
does what I didn't knew I wanted. :o)
--
Regards,
Thomas L�cke
Email: tl at ada-dk.org
Web: http:ada-dk.org
IRC nick: ThomasLocke
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Ada.Directories.Base_Name and dot files
2009-10-07 15:37 ` Yannick Duchêne Hibou57
@ 2009-10-11 2:39 ` Randy Brukardt
0 siblings, 0 replies; 17+ messages in thread
From: Randy Brukardt @ 2009-10-11 2:39 UTC (permalink / raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]
"Yannick Duch�ne Hibou57" <yannick_duchene@yahoo.fr> wrote in message
news:a38fc23f-7910-4f3c-afd6-a15669953de1@r36g2000vbn.googlegroups.com...
> On 7 oct, 17:10, Adam Beneschan <a...@irvine.com> wrote:
>> It was pointed
>> out that on Windows, a file named ".abc" is treated as any other file
>> with an extension of .abc
> That's a bit less clear on Windows
> Windows XP accept the file names as valid on its file system, but the
> Explorer does not allow to create such file names, complaining it is
> an invalid file name. But it is still able to access it.
There are lots of ways to create files on Windows that have nothing to do
with the file explorer (or the file save box). Anyone that writes an Ada
program to create a file will surely be able to create a file ".abc" if they
wish. The primary intent of Ada.Directories is that it can handle any file
that the other Ada I/O packages can open or create (no discussion about
explorer).
Randy.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Type casting
2009-10-08 9:58 `
@ 2009-10-26 19:26 ` Bruno
2009-10-26 20:02 ` Jeffrey R. Carter
2009-10-26 20:09 ` Adam Beneschan
2009-10-26 19:27 ` Conversions Bruno
1 sibling, 2 replies; 17+ messages in thread
From: Bruno @ 2009-10-26 19:26 UTC (permalink / raw)
Hi,
I have a small mess with the conversion of numeric types in the
following program
http://paste.ideaslabs.com/show/q6vOGqlyYJ
I really do not know how to interpret the operation (E / 2) because
although the operation is composed of two numbers such as "Positive"
outcome can be of type "Float" and, of course, the "Integer" (attribute)
returns an integer but the closest to real number and what
need my program is that it returns the integer part regardless
the decimal part.
I tried creating a small building under the following function
http://paste.ideaslabs.com/show/7y97bn4G6
but by requiring Float type parameters for the algorithm does not work
prev.
Can anyone shed some light on the conversion rate and the
problem presented to me?
Thank you.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Conversions
2009-10-08 9:58 `
2009-10-26 19:26 ` Type casting Bruno
@ 2009-10-26 19:27 ` Bruno
2009-10-26 20:09 ` Conversions Jeffrey R. Carter
2009-10-26 20:19 ` Conversions Adam Beneschan
1 sibling, 2 replies; 17+ messages in thread
From: Bruno @ 2009-10-26 19:27 UTC (permalink / raw)
Hi all,
I have a little problem with a function that "convert" a date, that is a
record type, into a string. To do this I'm using "image" attribute how
can you see in the following code
http://paste.ideaslabs.com/show/5KEJUGcDF
but when run the program and the function is executed a get an
"constraint error". The compiler show me a message that say that the
size is too long but I don't know what to do.
How can I repair this error?
Thanks,
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Type casting
2009-10-26 19:26 ` Type casting Bruno
@ 2009-10-26 20:02 ` Jeffrey R. Carter
2009-10-26 20:09 ` Adam Beneschan
1 sibling, 0 replies; 17+ messages in thread
From: Jeffrey R. Carter @ 2009-10-26 20:02 UTC (permalink / raw)
Bruno wrote:
>
> I really do not know how to interpret the operation (E / 2) because
> although the operation is composed of two numbers such as "Positive"
> outcome can be of type "Float" and, of course, the "Integer" (attribute)
> returns an integer but the closest to real number and what
> need my program is that it returns the integer part regardless
> the decimal part.
E is Positive, a subtype of Integer, so the expression "E / 2" is an Integer
expression, and converting it to Integer has no effect. "/" for Integer
truncates towards zero, which seems to be what you want.
The 'Truncation attribute function for floating-point types provides the integer
part.
--
Jeff Carter
"We call your door-opening request a silly thing."
Monty Python & the Holy Grail
17
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Type casting
2009-10-26 19:26 ` Type casting Bruno
2009-10-26 20:02 ` Jeffrey R. Carter
@ 2009-10-26 20:09 ` Adam Beneschan
1 sibling, 0 replies; 17+ messages in thread
From: Adam Beneschan @ 2009-10-26 20:09 UTC (permalink / raw)
On Oct 26, 12:26 pm, Bruno <brunomend...@gmail.com> wrote:
> Hi,
>
> I have a small mess with the conversion of numeric types in the
> following program
>
> http://paste.ideaslabs.com/show/q6vOGqlyYJ
>
> I really do not know how to interpret the operation (E / 2) because
> although the operation is composed of two numbers such as "Positive"
> outcome can be of type "Float" and, of course, the "Integer" (attribute)
> returns an integer but the closest to real number and what
> need my program is that it returns the integer part regardless
> the decimal part.
No, the outcome of E / 2 cannot be of type float. In some other
programming languages it can. But in Ada, if you divide two integers,
the result is an integer and is always truncated downward---the
remainder is thrown away. In this example, the type conversion
Integer (E/2) is redundant since the result of E/2 is already an
integer.
If you say Integer (Float (E) / 2.0) then the result of the division
would be a float, and it would round *upward* when converting to an
integer (if E is odd). But that isn't what you want for this
algorithm.
>
> I tried creating a small building under the following function
>
> http://paste.ideaslabs.com/show/7y97bn4G6
>
> but by requiring Float type parameters for the algorithm does not work
> prev.
I'm not sure what you mean. It looks like this second example was
trying to truncate a float to an integer (toward zero), and it appears
that it works fine. But you can do the same thing much more easily
with
return Integer (Float'Truncation (F));
Float'Truncation truncates F to an integer, truncating toward zero,
but it leaves the result as a Float; when you convert that to an
integer, no truncation or rounding is necessary since the result of
Float'Truncation already has an integral value.
Anyway, I'm not sure what about this doesn't work.
Hope this helps,
-- Adam
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Conversions
2009-10-26 19:27 ` Conversions Bruno
@ 2009-10-26 20:09 ` Jeffrey R. Carter
2009-10-26 20:19 ` Conversions Adam Beneschan
1 sibling, 0 replies; 17+ messages in thread
From: Jeffrey R. Carter @ 2009-10-26 20:09 UTC (permalink / raw)
Bruno wrote:
>
> I have a little problem with a function that "convert" a date, that is a
> record type, into a string. To do this I'm using "image" attribute how
> can you see in the following code
>
> http://paste.ideaslabs.com/show/5KEJUGcDF
>
> but when run the program and the function is executed a get an
> "constraint error". The compiler show me a message that say that the
> size is too long but I don't know what to do.
'Image for an integer type returns the shortest string necessary to represent
the value, with ' ' added to the front for a positive value and '-' for a
negative value.
Thus we can get
6 => " 6"
-6 => "-6"
10 => " 10"
-10 => "-10"
For your application (date image), 2-digit day and month numbers are likely;
their 'Image will not fit in 2 characters.
You can save the 'Image and decide what to do with it:
declare
Day_Image : constant String := Integer'Image (F.Dia);
begin
if F.Dia < 10 then
S (1) := '0';
S (2) := Day_Image (Day_Image'Last);
else
S (1 .. 2) := Day_Image (Day_Image'Last - 1 .. Day_Image'Last);
end if;
end;
You can also look at the operations in Ada.Text_IO.Integer_IO that write to a
String parameter.
--
Jeff Carter
"We call your door-opening request a silly thing."
Monty Python & the Holy Grail
17
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Conversions
2009-10-26 19:27 ` Conversions Bruno
2009-10-26 20:09 ` Conversions Jeffrey R. Carter
@ 2009-10-26 20:19 ` Adam Beneschan
1 sibling, 0 replies; 17+ messages in thread
From: Adam Beneschan @ 2009-10-26 20:19 UTC (permalink / raw)
On Oct 26, 12:27 pm, Bruno <brunomend...@gmail.com> wrote:
> Hi all,
>
> I have a little problem with a function that "convert" a date, that is a
> record type, into a string. To do this I'm using "image" attribute how
> can you see in the following code
>
> http://paste.ideaslabs.com/show/5KEJUGcDF
>
> but when run the program and the function is executed a get an
> "constraint error". The compiler show me a message that say that the
> size is too long but I don't know what to do.
'Image returns a string whose first character is a space if the
argument is not negative. So if N = 12, then Integer'Image(N) = "
12"---i.e. 3 characters. That won't fit in the two-character slice
you're trying to put it in, so you get a Constraint_Error.
But just getting rid of the space doesn't work either. If N = 1, then
Integer'Image(N) = " 1", and if you were able to trim off the space,
the result would be "1", and you'd still get a Constraint_Error. When
you assign a slice like this, the left and right sides must be the
same length.
There are a number of ways to do what you want, but I'd suggest
looking at the Ada.Strings.Fixed package, especially the Move, Trim,
and Tail routines.
Hope this helps,
-- Adam
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2009-10-26 20:19 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-10-07 12:40 Ada.Directories.Base_Name and dot files
2009-10-07 14:46 ` Yannick Duchêne Hibou57
2009-10-07 17:06 `
2009-10-07 14:52 ` Adam Beneschan
2009-10-07 17:06 `
2009-10-07 15:10 ` Adam Beneschan
2009-10-07 15:37 ` Yannick Duchêne Hibou57
2009-10-11 2:39 ` Randy Brukardt
2009-10-07 20:11 `
2009-10-08 9:39 ` Stephen Leake
2009-10-08 9:58 `
2009-10-26 19:26 ` Type casting Bruno
2009-10-26 20:02 ` Jeffrey R. Carter
2009-10-26 20:09 ` Adam Beneschan
2009-10-26 19:27 ` Conversions Bruno
2009-10-26 20:09 ` Conversions Jeffrey R. Carter
2009-10-26 20:19 ` Conversions Adam Beneschan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox