Next attempt to replace C/C++ without really replacing it: Carbon!
You will notice, as usual, a few aspects borrowed from Ada - and one point inspired by Ada 83 (which was relaxed in a later Ada version) :-)
Next attempt to replace C/C++ without really replacing it: Carbon!
We have just learned how dangerous is carbon for our climate. Yet these
few privileged keep on pumping it up! (:-))
Next attempt to replace C/C++ without really replacing it: Carbon!
Next attempt to replace C/C++ without really replacing it: Carbon!
You will notice, as usual, a few aspects borrowed from Ada - and one point inspired by Ada 83 (which was relaxed in a later Ada version) :-)
On 2022-07-22 23:13, Gautier write-only address wrote:
Next attempt to replace C/C++ without really replacing it: Carbon!
Wouldn't this be an attempted replacement for Google's previous attempt
to replace C-family languages, Go?
On 22/07/2022 22:13, Gautier write-only address wrote:
Next attempt to replace C/C++ without really replacing it: Carbon!Saw this last week and immediately thought they'd failed on one of their "design goals," i.e. to be "readable.
You will notice, as usual, a few aspects borrowed from Ada - and one point inspired by Ada 83 (which was relaxed in a later Ada version) :-)What did they take from Ada?
Certainly not the approach to making life easier and less error-prone for developers.
I've got involved in a couple of discussions on their forum, and I'm inclined to think they just want C++ but taken out of the control of ISO/IEC WGs steering committees.
They're pretty much not considering changing any of the aspects of C++ that make it such a heap of junk (IMO, of course), including, but not limited to:
1. arraysbecome relatively successful have taken a good 10 years or so to get to that point, yet the discussions on the Carbon forum are all about how to appeal to _current_ developers who're used to C++; not _future_ developers who, ideally, would _never_ be
2. enums
3. (both of the above when used together :-))
4. symbols - overuse, duplication, inconsistency
5. implicit stuff
6. pretend strong typing
7. forcing developers to deal manually with numeric values that don't fit into an n-byte range, where n is a whole number
It really is shockingly soul-destroying watching all that. What's worse is that, from what I've seen over the years, the new languages that have been developed in a more 'relaxed' way than Ada (well, evolved, really, like Java, Python etc) and have
1. arrays
2. enums
3. (both of the above when used together :-))
4. symbols - overuse, duplication, inconsistency
5. implicit stuff
6. pretend strong typing
7. forcing developers to deal manually with numeric values that don't fit into an n-byte range, where n is a whole number
It really is shockingly soul-destroying watching all that. What's worse is that, from what I've seen over the years, the new languages that have been developed in a more 'relaxed' way than Ada (well, evolved, really, like Java, Python etc) and havebecome relatively successful have taken a good 10 years or so to get to that point, yet the discussions on the Carbon forum are all about how to appeal to _current_ developers who're used to C++; not _future_ developers who, ideally, would _never_ be
On 26/07/2022 18:31, John McCabe wrote:
It really is shockingly soul-destroying watching all that. What's worseIt's depressing dealing with cretin's who all think they're geniuses and think that their new idea is so radically different, but is just the
is that, from what I've seen over the years, the new languages that
have been developed in a more 'relaxed' way than Ada (well, evolved,
really, like Java, Python etc) and have become relatively successful
have taken a good 10 years or so to get to that point, yet the
discussions on the Carbon forum are all about how to appeal to
_current_ developers who're used to C++; not _future_ developers who,
ideally, would _never_ be used to C++!
same old crap wrapped up in a functional style.
"Please stop. Our moderators are empowered to decide if conduct is
within our norms our not. The conduct team acts as a check to ensure
they are correct. We have thoroughly reviewed and agree all the
moderators involved in this are correct."
On Wed, 27 Jul 2022 09:10:10 +0100, Luke A. Guest wrote:
It's depressing dealing with cretin's who all think they're geniuses and
think that their new idea is so radically different, but is just the
same old crap wrapped up in a functional style.
LOL - yeah, tell me about it. In this thread that I mentioned (https:// github.com/carbon-language/carbon-lang/discussions/1720), I pointed out a
few things that I'm unhappy with in C++ that, in Ada, are "solved" and
have been for decades. The result is that someone who appears to have
very little software development experience misinterpreted the comments
about half-baked features and locked the thread.
Now, personally, if I were in a position where I was tasked to uphold a
code of conduct whose aims were to provide a welcoming forum, and not
being nasty to people, my response to this would NOT be:
"Please stop. Our moderators are empowered to decide if conduct is
within our norms our not. The conduct team acts as a check to ensure
they are correct. We have thoroughly reviewed and agree all the
moderators involved in this are correct."
While the hypocrisy left me almost speechless, I did have to laugh :-)
In this thread that I mentioned (https:// github.com/carbon-language/carbon-lang/discussions/1720), I pointed
out a few things that I'm unhappy with in C++ that, in Ada, are
"solved" and have been for decades.
John McCabe <john@nospam.mccabe.org.uk> writes:
In this thread that I mentioned (https://
github.com/carbon-language/carbon-lang/discussions/1720), I pointed
out a few things that I'm unhappy with in C++ that, in Ada, are
"solved" and have been for decades.
"Avoid keyword duplication"?? e.g. multiple uses of 'with'?
On 27/07/2022 18:24, John McCabe wrote:
few things that I'm unhappy with in C++ that, in Ada, are "solved" and
have been for decades. The result is that someone who appears to have
Yup.
May be there is something in Ada that preventing it from being
widely adopted and used?
On 7/27/2022 3:00 PM, Luke A. Guest wrote:
On 27/07/2022 18:24, John McCabe wrote:
Since Ada has solved these problems long time ago, then why are peoplefew things that I'm unhappy with in C++ that, in Ada, are "solved" and
have been for decades. The result is that someone who appears to have
Yup.
still re-inenting the wheel? Why are they not just using Ada? Ada is
free software.
The alternative would be to go and join a team that's already
using Ada, but every Ada job I've seen come up locally is to support code that was written in Ada 95; I'd rather be looking at Ada 2005 -> if I was
to make that jump.
May be people just like { } instead of Begin, End?
Or may be there is something else going on.
Or may be there is something else going on.
IMHO the only way to make Ada more popular is to create popular applications with it.
"Nasser M. Abbasi" <nma@12000.org> writes:
Or may be there is something else going on.
It seems to me that it simply takes a lot more code (not just
keystrokes) to do anything in Ada, compared to other languages. Having
two files (ADS and ADB) for every module is already a nuisance.
I think there is also a very big gap between beginner-level Ada and production-level Ada, and it's not very obvious how to bridge the gap.
C++ has tons of online docs and you can learn what you need to
gradually. Plus it is easier to navigate C++'s library ecosystem.
Alire(sp?) may help with that for Ada. I haven't used it yet.
Looking at some of the languages that have come out in recent years, it's obvious that people can't be bothered to type much; "fn"/"def" (or, even, nothing!) instead of "function"/"procedure", "{"/"}" instead of "begin"/"end", "&&" instead of "and", "||" instead of "or" (!!!) etc.
From what I can see, some of the "moderators" on that Carbon group don't have much real (...)
I suspect
they really have no clue about what they could achieve with Ada,
However, from the point of view of creating a new language, the fact that
so many people clearly think it _has_ to be the C/C++ way is quite disturbing, especially since, as I think I mentioned, it's going to be a number of years until any new language really makes its mark, so new languages should be taking future developers into account, not just
pandering to the laziness of existing ones!
Le vendredi 29 juillet 2022 à 13:03:39 UTC+2, John McCabe a écrit :
The alternative would be to go and join a team that's already
using Ada, but every Ada job I've seen come up locally is to support code
that was written in Ada 95; I'd rather be looking at Ada 2005 -> if I was
to make that jump.
It should not be a problem, since each version of Ada is compatible with the previous one.
You can bring in whatever new feature is supported, especially in new packages or projects.
It's only a problem if your boss requires to stick with Ada 95.
The main issue is: out of the dozens of languages around, how can someone >guess that language X has solved Y's issues?
May be there is something in Ada that preventing it from being
widely adopted and used?
* There's no modern book in german about modern Ada and its libraries
* There's no syntaxhighlighting package in vim for ada
* No exercises like for example Ruby Koans
* It *Looks* like there are no libraries which make it easy use Ada for programming (think json/document formats, http/mail/mime protocols,
algorithms or cryptography libraries)
If someone would write a book in german, how to write Ada and use $cryptolibrary, $networklibrary and how to integrate it in ones favorite development software, this surely would be very interesting too many.
On 06.08.22 16:18, dennis knorr wrote:
* There's no modern book in german about modern Ada and its libraries
What's the competition, considering C#, Swift, Java or C?
I.e., an original work written by a German author, bought
and studied by many?
There used to be a number of books on Ada written in German when
the market had developed ideas of a government mandate, the ideas
producing corresponding opportunities.
* There's no syntaxhighlighting package in vim for ada
:syntax enable
(Does vim feature in a modern feeling tool chain, though?)
* No exercises like for example Ruby Koans
* It *Looks* like there are no libraries which make it easy use Ada for
programming (think json/document formats, http/mail/mime protocols,
AWS, GNATColl, $ alr with json.
algorithms or cryptography libraries)
Just use one that you can trust. If you need it to be more Ada-ish,
ChaCha20 cipher and Poly1305 digest have just been mentioned a few
postings ago. If algorithms can address securing the entire computation...
There used to be the PAL, which is the Public Ada Library, easy to find.
A bit dated, and reflecting the hype back then, I guess.
I gather that, currently, and in the past, Ada tools are also focusing
on topics of embedded computers, a fairly large and attractive market.
JSON or MIME, perhaps even interpreters are present, but I think not
central to control stuff near sensors and actuators. How does one compute deterministic responses before deadline using Node.js?
If someone would write a book in german, how to write Ada and use
$cryptolibrary, $networklibrary and how to integrate it in ones favorite
development software, this surely would be very interesting too many.
Can you say how many? I imagine a publisher asking this question.
Am 07.08.22 um 11:08 schrieb G.B.:
Just use one that you can trust. If you need it to be more Ada-ish,
ChaCha20 cipher and Poly1305 digest have just been mentioned a few
postings ago. If algorithms can address securing the entire computation...
The deeper you dig with crypto the more problems you have. For example,
with TLS terminations, Chacha/salsa/Poly does not help you. Or you want
to interact with other data structures which implement AES with GCM or
you need cryptoprotocol elements for a KeyExchange, even without
implementing TLS?
I gather that, currently, and in the past, Ada tools are also focusing
on topics of embedded computers, a fairly large and attractive market.
JSON or MIME, perhaps even interpreters are present, but I think not
central to control stuff near sensors and actuators.
How does one compute
deterministic responses before deadline using Node.js?
but
because of the elitist complacency. With attitudes like this, Ada will
only continue withering in the future.
P.S. Nobody writes Ada books these days because they do not sell.
When someone starts talking about books, I think they're a troll.
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message >news:tcs2mr$1o0u$1@gioia.aioe.org...
...
P.S. Nobody writes Ada books these days because they do not sell.
Do *any* programming books really sell? If so, why? :-)
There are plenty of free, on-line resources for pretty much any programming >language. Why pay for something you can get free?
"Dmitry A. Kazakov" wrote in message
...
P.S. Nobody writes Ada books these days because they do not sell.Do *any* programming books really sell? If so, why? :-)
of the three recent ones I find, only the Barnes book is of good
quality. I'd be delighted if someone would prove me wrong.
On Monday, August 8, 2022 at 11:12:48 PM UTC-5, Randy Brukardt wrote:95, and I'm not sure it's in print anymore. In fact, and alas, only three of the Ada-based textbooks I find "easily" on Amazon date from the early- to mid-90s, and of the three recent ones I find, only the Barnes book is of good quality.
"Dmitry A. Kazakov" wrote in message
...
P.S. Nobody writes Ada books these days because they do not sell.Do *any* programming books really sell? If so, why? :-)
Having recently left a university, I can attest that schoolbooks are still a thing, and that includes textbooks on computer programming. I recently inherited from a member of this forum a nice textbook on Data Structures in Ada, but it was based on Ada
I'd be delighted if someone would prove me wrong.
On Wednesday, August 10, 2022 at 1:20:45 AM UTC-5, Paul Rubin wrote:
Analysable Real-Time Systems: Programmed in Ada by Prof. Alan Burns is
from 2016 and looks pretty good. It is the book I mentioned that I got
on the recommendation of someone here. I've flipped through it but
still haven't read it.
I hadn't seen that one; thanks!
Analysable Real-Time Systems: Programmed in Ada by Prof. Alan Burns is
from 2016 and looks pretty good. It is the book I mentioned that I got
on the recommendation of someone here. I've flipped through it but
still haven't read it.
The only Ada95 DS book I know of is the one I have by Mark Weiss.
On Wednesday, August 10, 2022 at 3:26:44 AM UTC-5, Luke A. Guest wrote:
The only Ada95 DS book I know of is the one I have by Mark Weiss.
The one is have is by Feldman.
The result is that someone who appears to have
very little software development experience misinterpreted the comments
about half-baked features and locked the thread.
There are obviously changes that we'd like to make to C++, but calling C++ "half-baked" is demeaning to those who have invested years of work into that project.
TBH, this whole project just appears to be Google trying to detract from RustThis is disrespectful to everyone working on the Carbon Language project.
On Wednesday, July 27, 2022 at 7:24:58 PM UTC+2, John McCabe wrote:
The result is that someone who appears to have
very little software development experience misinterpreted the comments about half-baked features and locked the thread.
I think they did the right thing. And provided explanations:
There are obviously changes that we'd like to make to C++, but calling C++ "half-baked" is demeaning to those who have invested years of work into that project.
TBH, this whole project just appears to be Google trying to detract from RustThis is disrespectful to everyone working on the Carbon Language project.
I agree with both.
I don't know if the people working on Carbon had a bad opinion about Ada before, but sure do now.
In the end I think that you did a lot of damage to Ada, its reputation and its community...
Assertive and strongly-worded? sure, but aggressive?
Do language designers really draw conclusions about the quality of other languages, or even about the user community of other languages, from a handful of posts by one zealous member?Not if they are rational people. A member, a couple of members do not make a community; basic set theory.
Olivier Henley writes:
This is not aggression. We need to stop relativizing definitions.I would call the first post somewhat aggressive, though not intensely
so. (...) The second post came across to me as even more aggressive ("Can you please specify...").
Hordes of people wrote that (along those lines --> "Ada typing isThis is a general, open discussion forum, not the equivalent of an
nonsense, crazy, mad, stupid, etc") and nobody in this community ever canceled them by weaponizing, eg.: "it is demeaning to people working
on the ARG" ... therefore this is aggression.
internal forum of the ARG itself. I could understand if an internal ARG
forum locked threads calling Ada typing nonsense, crazy, mad, stupid, etc.
If there is no intentional wordplay between "Rust" and "Carbon", IMaybe you are right about that, but it hadn't occurred to me. Rust is
will be damned.
iron oxide and carbon is a different element.
This is not aggression. We need to stop relativizing definitions.
Hordes of people wrote that (along those lines --> "Ada typing is
nonsense, crazy, mad, stupid, etc") and nobody in this community ever canceled them by weaponizing, eg.: "it is demeaning to people working
on the ARG" ... therefore this is aggression.
If Ada is not a direct contender to C++ since 1983, I will be damned.
If there is no intentional wordplay between "Rust" and "Carbon", I
will be damned.
If C++ is "fully baked" and still needs Carbon, I will be damned.
I guess my real point was, the guy is willing to take the heat,
bluntly asking questions I definitely share.
Olivier Henley <olivier...@gmail.com> writes:
I guess my real point was, the guy is willing to take the heat,It was possible to make the exact same points more neutrally. Beyond
bluntly asking questions I definitely share.
that though, I didn't see evidence that the guy had looked at Carbon in
any detail. The criticisms were purely of C++, so I would consider that
a low-effort post. And the part about abandoning Carbon was dismissive
toward the whole Carbon project. The Carbon github site is surely the
wrong place for that.
Sometimes, on that subject, telling people they should know better is
really hard to resist.
If there is no intentional wordplay between "Rust" and "Carbon", I will be damned.
On 10/08/2022 02:19, John Perry wrote:Ada 95, and I'm not sure it's in print anymore. In fact, and alas, only three of the Ada-based textbooks I find "easily" on Amazon date from the early- to mid-90s, and of the three recent ones I find, only the Barnes book is of good quality.
On Monday, August 8, 2022 at 11:12:48 PM UTC-5, Randy Brukardt wrote:
"Dmitry A. Kazakov" wrote in message
...
P.S. Nobody writes Ada books these days because they do not sell.Do *any* programming books really sell? If so, why? :-)
Having recently left a university, I can attest that schoolbooks are still a thing, and that includes textbooks on computer programming. I recently inherited from a member of this forum a nice textbook on Data Structures in Ada, but it was based on
I'd be delighted if someone would prove me wrong.
The only Ada95 DS book I know of is the one I have by Mark Weiss.
On 2022-08-26 20:59, Olivier Henley wrote:
If there is no intentional wordplay between "Rust" and "Carbon", I
will be damned.
Carbon's symbol is C, so I presumed that was where the name came from.
Of course, that means Carbon and C are the same thing ...
On 27/8/22 09:21, Jeffrey R.Carter wrote:
On 2022-08-26 20:59, Olivier Henley wrote:
If there is no intentional wordplay between "Rust" and "Carbon", I
will be damned.
Carbon's symbol is C, so I presumed that was where the name came from.
Of course, that means Carbon and C are the same thing ...
So the next incarnation of Ada might be Adamantium ? ... :)
On Wednesday, July 27, 2022 at 7:24:58 PM UTC+2, John McCabe wrote:
The result is that someone who appears to have
very little software development experience misinterpreted the comments
about half-baked features and locked the thread.
I think they did the right thing. And provided explanations:
I don't know if the people working on Carbon had a bad opinion about Ada before, but sure do now.
In the end I think that you did a lot of damage to Ada, its reputation and its community...
On Thursday, August 25, 2022 at 4:14:02 AM UTC-5, Fabien Chouteau wrote:
On Wednesday, July 27, 2022 at 7:24:58 PM UTC+2, John McCabe wrote:
The result is that someone who appears to have
very little software development experience misinterpreted the comments
about half-baked features and locked the thread.
I think they did the right thing. And provided explanations:
There are obviously changes that we'd like to make to C++, but calling C++ "half-baked" is demeaning to those who have invested years of work into that project.I agree with both.
TBH, this whole project just appears to be Google trying to detract from RustThis is disrespectful to everyone working on the Carbon Language project. >>
I can agree with the statements you've quoted, and I can agree with their closing the thread (they didn't delete it!) but he also called them "aggressive" statements, and that's simply untrue. Assertive and strongly-worded? sure, but aggressive?
Olivier Henley <olivier.henley@gmail.com> writes:
This is not aggression. We need to stop relativizing definitions.
I would call the first post somewhat aggressive, though not intensely
so. It dinged on the C++ community ("I find it shocking...")
and
suggested by apophasis ( https://en.wikipedia.org/wiki/Apophasis ) that
the Carbon devs should abandon their project and using Ada instead
("that might not be a bad idea").
It also treated some debateable
points as self-evident, such as that enumeration types should always
support 'Image.
It seems reasonable to me for the Carbon forum moderators to disallow
and shut down language debates of any kind, even if they are not
aggressive per se. We've all seen enough of those to know how they go.
That particular language debate was especially off-topic since it was an
Ada vs C++ comparison on a Carbon forum. Ada vs Carbon would have been >better.
The second post came across to me as even more aggressive ("Can you
please specify..."). It was full of what is sometimes called
"sea-lioning", a classic passive-aggressive debating technique:
https://en.wikipedia.org/wiki/Sealioning
I didn't read the later posts that were flagged as off-topic, since you
have to be logged in to view them.
Hordes of people wrote that (along those lines --> "Ada typing is
nonsense, crazy, mad, stupid, etc") and nobody in this community ever
canceled them by weaponizing, eg.: "it is demeaning to people working
on the ARG" ... therefore this is aggression.
This is a general, open discussion forum, not the equivalent of an
internal forum of the ARG itself. I could understand if an internal ARG >forum locked threads calling Ada typing nonsense, crazy, mad, stupid, etc.
If C++ is "fully baked" and still needs Carbon, I will be damned.
I haven't looked into Carbon much, but C++ is hampered by having to
support 40 years of legacy code.
Carbon doesn't have to be backwards
compatible at the language level, as long as it can interoperate.
Olivier Henley <olivier.henley@gmail.com> writes:
I guess my real point was, the guy is willing to take the heat,
bluntly asking questions I definitely share.
It was possible to make the exact same points more neutrally. Beyond
that though, I didn't see evidence that the guy had looked at Carbon in
any detail.
The criticisms were purely of C++, so I would consider that
a low-effort post.
And the part about abandoning Carbon was dismissive
toward the whole Carbon project. The Carbon github site is surely the
wrong place for that.
However I've now come to believe the aim of the Carbon team is to re-create C++ but in a way that doesn't require new features and changes to go
through the standardisation hoops that C++ goes through, i.e. so they can basically change it at will (makes me think of early Java, where
depreciation was very, very common).
John McCabe <john@nospam.mccabe.org.uk> writes:
However I've now come to believe the aim of the Carbon team is to re-create >> C++ but in a way that doesn't require new features and changes to go
through the standardisation hoops that C++ goes through, i.e. so they can
basically change it at will (makes me think of early Java, where
depreciation was very, very common).
Have they been changing Go at will? I don't have that impression.
I do think they want to shed a lot of assumptions that were valid or
sensible at the time C++ was first designed, and also to not have their >design choices constrained by C++ legacy support.
Go is sort of a recreation of C, with garbage collection and cooperative >multitasking baked into the language. It otherwise has a fairly similar >execution model and type system. It's not a C++ replacement both
because of its GC dependence and its weaker type system.
I haven't used Rust, but from what I can understand, its type system is >Haskell-inspired and more modern than either C++'s or Ada's. Compared
with C++, it gives its user better hope of code correctness through its
use of safe defaults like immutable values and unique pointer ownership.
You can override the defaults and get similar non-safety to C++, if you
need that for some reason.
What then is Carbon? I don't know, and I'm not convinced that you do
either.
That wasn't the point; the point is, as I mentioned, that _new_ features are being added that are not fully designed/defined/implemented; look at, for example, the excuse for the missing operator+() on std::filesystem::path.
Yet they're happy to adopt many of C++'s legacy syntactic/semantic issues, e.g. assignment produces a result that can be implicitly converted to a boolean and used in a conditional which, when considered at the same time
as the use of "=" for assignment, and "==" for comparison, has caused numerous issues and head-scratching over the years.
Stepanov reminds us that "+" is commutative...
as the use of "=" for assignment, and "==" for comparison, has caused numerous issues and head-scratching over the years.
You are quite right; I have little clue what Carbon is
John McCabe <jo...@nospam.mccabe.org.uk> writes:
as the use of "=" for assignment, and "==" for comparison, has caused numerous issues and head-scratching over the years.If that is your only concrete objection to Carbon,
Also the convenience of being able to compare two objects forA'Has_Same_Storage (B);
being the same object, using "===" in some languages---out of the box!
procedure same_object (A : T; B in out T) is
begin
what_do_i_put_here; -- ?
end same_object;
On 01.09.22 08:46, J-P. Rosen wrote:Yes. There is also A'Overlaps_Storage (B) which is True if A and B have
Le 28/08/2022 à 19:34, G.B. a écrit :
Also the convenience of being able to compare two objects forA'Has_Same_Storage (B);
being the same object, using "===" in some languages---out of the box!
procedure same_object (A : T; B in out T) is
begin
what_do_i_put_here; -- ?
end same_object;
Of course, this procedure should be a function...
Cool, new attributes.
Is the expectation that A and B occupy the same
bits if I pass the same X as an actual for both?
Le 28/08/2022 à 19:34, G.B. a écrit :
Also the convenience of being able to compare two objects forA'Has_Same_Storage (B);
being the same object, using "===" in some languages---out of the box!
procedure same_object (A : T; B in out T) is
begin
what_do_i_put_here; -- ?
end same_object;
Of course, this procedure should be a function...
Le 02/09/2022 à 16:18, G.B. a écrit :
On 01.09.22 08:46, J-P. Rosen wrote:Yes.
Le 28/08/2022 à 19:34, G.B. a écrit :
Also the convenience of being able to compare two objects forA'Has_Same_Storage (B);
being the same object, using "===" in some languages---out of the box! >>>>
procedure same_object (A : T; B in out T) is
begin
what_do_i_put_here; -- ?
end same_object;
Of course, this procedure should be a function...
Cool, new attributes.
Is the expectation that A and B occupy the same
bits if I pass the same X as an actual for both?
On 2022-09-02 17:59, J-P. Rosen wrote:
Le 02/09/2022 à 16:18, G.B. a écrit :
On 01.09.22 08:46, J-P. Rosen wrote:Yes.
Le 28/08/2022 à 19:34, G.B. a écrit :
Also the convenience of being able to compare two objects forA'Has_Same_Storage (B);
being the same object, using "===" in some languages---out of the box! >>>>>
procedure same_object (A : T; B in out T) is
begin
what_do_i_put_here; -- ?
end same_object;
Of course, this procedure should be a function...
Cool, new attributes.
Is the expectation that A and B occupy the same
bits if I pass the same X as an actual for both?
Surely only if their type (T, above) is passed by-reference?
G.B.'s post had a later example where T is "range 1 .. 10", which is a by-copy type, so there A and B would be separate copies of X.
On 2022-09-02 17:59, J-P. Rosen wrote:
Le 02/09/2022 16:18, G.B. a crit :
On 01.09.22 08:46, J-P. Rosen wrote:
Le 28/08/2022 19:34, G.B. a crit :
Also the convenience of being able to compare two objects forA'Has_Same_Storage (B);
being the same object, using "===" in some languages---out of the box! >>>>>
procedure same_object (A : T; B in out T) is
begin
what_do_i_put_here; -- ?
end same_object;
Of course, this procedure should be a function...
Cool, new attributes.
Yes.
Is the expectation that A and B occupy the same
bits if I pass the same X as an actual for both?
Surely only if their type (T, above) is passed by-reference?
G.B.'s post had a later example where T is "range 1 .. 10", which is a by-copy type, so there A and B would be separate copies of X.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 360 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 129:45:31 |
| Calls: | 7,686 |
| Files: | 12,828 |
| Messages: | 5,711,157 |