David Brown <david.brown@hesbynett.no>: Apr 30 09:21PM +0200
On 29/04/16 20:28, Jerry Stuckle wrote:
> printf("BIGENDIAN");
> return 0;
> }
That is runtime only - it does not generate a constant expression. And
it is not portable to systems where sizeof(short) == 1.
>
red floyd <no.spam.here@its.invalid>: Apr 19 10:38PM -0700
On 4/19/2016 7:09 AM, Scott Lurndal wrote:
> and useful addressing modes.
>> they were on the inside. Possibly put off by PIP and STAT commands. :(
> Should have used UnixV6 instead of RSX-11M/RSTS-E.
The TI 34010 Graphics processor communicated with the host CPU via
memory mapped registers. You'd load the address register with the
address in 34010 memory space, and then write to the data register.
Successive writes would increment the address register, so that you
could load graphics data by successive writes to the data register.
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 29 10:40AM -0400
On 4/29/2016 1:20 AM, Öö Tiib wrote:
> defines object or library file formats or application binary interfaces
> so they can. You however very verbosely keep failing to give examples of
> users of that freedom in Unix land.
And you can keep demanding all you want. One of these days, I might be
talking to one of my past clients and get the details. I don't remember
what every client I ever worked with runs.
But it's not important enough to me to bug them with trivial questions.
However, everyone else here seems to claim that ar is required to build
.a files, and all .o files are the same format. It shows just how
limited your experience is.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 29 10:42AM -0400
On 4/29/2016 4:14 AM, Ian Collins wrote:
>> it wasn't gcc. However, it's not important enough for me to give a damn.
> So as usual you can't back up your nonsensical claims. Why do you
> bother posting bollocks? I guess you don't give a damn.
Nope, it's just not important enough for me to try to teach a pig to
sing. Your comments prove the extent of your ignorance.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 29 10:43AM -0400
On 4/29/2016 8:46 AM, Scott Lurndal wrote:
>> the educational world. Not even AT&T was using it very much for production.
> Interesting, indeed, as I was working for a University on
> a PDP-11/34 writing unix drivers for test hardware.
Let's see. You were working for a University. I said they were used in
the educational world. I guess to you a University is not part of the
educational world.
I guess you never learned comprehension at your "university".
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
| "Öö Tiib" <ootiib@hot.ee>: Apr 29 08:44AM -0700
On Friday, 29 April 2016 17:41:06 UTC+3, Jerry Stuckle wrote:
> talking to one of my past clients and get the details. I don't remember
> what every client I ever worked with runs.
> But it's not important enough to me to bug them with trivial questions.
I do not demand. I say that it leaves your assertions bald and empty
denial of reality.
> However, everyone else here seems to claim that ar is required to build
> .a files, and all .o files are the same format. It shows just how
> limited your experience is.
You are moving goalposts here. Others claim that with advent of portable
operating systems some object file formats have been defined and used
on different kinds of systems. The formats are not used because someone
requires that. Formats are used because everybody wants to achieve
compatibility with others. Who does not falls out of pack and loses.
No one is required to make say .zip files using a PKZIP program and if
they use something else they are still not required to produce ZIP
format specified by ISO/IEC 21320-1:2015. Everybody just wants to.
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 29 12:23PM -0400
On 4/29/2016 11:44 AM, Öö Tiib wrote:
>> But it's not important enough to me to bug them with trivial questions.
> I do not demand. I say that it leaves your assertions bald and empty
> denial of reality.
And what you think is of absolutely no importance to me.
> on different kinds of systems. The formats are not used because someone
> requires that. Formats are used because everybody wants to achieve
> compatibility with others. Who does not falls out of pack and loses.
No, I have moved no goalposts. My statements have been consistent since
the start. Just because your limited experience hasn't exposed you to
other options does not mean they don't exist.
> No one is required to make say .zip files using a PKZIP program and if
> they use something else they are still not required to produce ZIP
> format specified by ISO/IEC 21320-1:2015. Everybody just wants to.
Now who's moving the goalposts - or at least bringing up another red
herring?
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 29 02:28PM -0400
On 4/28/2016 5:01 PM, David Brown wrote:
> made it perfectly clear that I don't believe it can be done, and
> certainly don't know of any method. I have also made it clear that I
> will be happy to be proven wrong here.
Since you're completely incapable of a small challenge, here's how you
can do it:
file: endian.c:
===
#include <stdio.h>
union endian {
short s;
char c[sizeof(short)];
};
int main(void) {
union endian endian;
endian.s = 1;
if (endian.c[0])
printf("LITTLEENDIAN");
else
printf("BIGENDIAN");
return 0;
}
===
gcc endian.c -o endian
file: endiantest.c:
===
#include <stdio.h>
int main(void) {
#ifdef BIGENDIAN
printf("Big Endian defined\n");
#elif defined LITTLEENDIAN
printf("Little Endian defined\n");
#else
printf("No endian defined\n");
Sent from my iPad
Begin forwarded message:
From: Sharon Kahn < sharon62kahn@gmail.com> Date: April 27, 2016 at 7:08:34 PM CDT Subject: Fwd: 凱特王妃美衣風采被搶光？喬治小王子穿睡衣都能殺光底片！
Subject: Fwd: Fwd: 凱特王妃美衣風采被搶光？喬治小王子穿睡衣都能殺光底片！
凱特王妃美衣風采被搶光？喬治小王子穿睡衣都能殺光底片！ -- 英女王伊莉莎白二世90大壽！小喬治與夏綠蒂合體祝福太可愛了吧！
"Öö Tiib" <ootiib@hot.ee>: Apr 28 10:20PM -0700
On Thursday, 28 April 2016 22:28:15 UTC+3, Jerry Stuckle wrote:
> > (pretty much like 'tar') and not some sort of gcc tool.
> Which does not mean that other tools can't include their own versions of
> library creation tools.
No one in this thread has said they can't. Neither C nor C++ standard
defines object or library file formats or application binary interfaces
so they can. You however very verbosely keep failing to give examples of
users of that freedom in Unix land.
| Paavo Helde <myfirstname@osa.pri.ee>: Apr 29 08:21AM +0300
On 29.04.2016 0:50, David Brown wrote:
> A cross-compiler could pre-calculate the result of this expression at
> compile time - it knows the endianness of the target and can get this
> sort of thing right. But of course it is still not a constant expression.
This would basically require that in addition of generating machine code
the compiler would also contain a virtual machine for executing this
code. To my understanding, reinterpret_cast is forbidden in constexpr
exactly in order to avoid such burdens.
Cheers
Paavo
| Ian Collins <ian-news@hotmail.com>: Apr 29 08:10PM +1200
On 04/29/16 10:09, Richard wrote:
> archive shall be printable."
> <http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ar.html>
> Neat! I didn't know that.
Neither did I, which just goes to show that most of us are never too old
to learn :)
--
Ian Collins
| Ian Collins <ian-news@hotmail.com>: Apr 29 08:14PM +1200
On 04/29/16 09:39, Jerry Stuckle wrote:
> One of these days when I get around to it, I'll get ahold of one of my
> past customers and see what they use. I don't remember right now, but
> it wasn't gcc. However, it's not important enough for me to give a damn.
So as usual you can't back up your nonsensical claims. Why do you
bother posting bollocks? I guess you don't give a damn.
--
Ian Collins
| David Brown <david.brown@hesbynett.no>: Apr 29 01:10PM +0200
On 29/04/16 07:21, Paavo Helde wrote:
> This would basically require that in addition of generating machine code
> the compiler would also contain a virtual machine for executing this
> code.
No, it is much simpler than that. For a case like this, the compiler
only needs to know the endianness of the target and it can figure out
the result - there is no need for full simulations. Note - I have tied
this code, as:
bool isLittleEndian(void) {
const int dummy = 1;
bool little_endian = *(reinterpret_cast<char *> (&dummy));
return little_endian;
}
A cross-compiler for embedded ARM devices optimised this to a simple
"return true;" equivalent.
Powerful compilers have quite complex simulators and target evaluators
built in. gcc is quite happy with a 32-bit host doing compile-time
calculation of the results of 64-bit or 128-bit arithmetic on a
different target. It will even do so for floating point, getting
bit-accurate results. (If it can't get bit-accurate results, it falls
back to generating run-time code for the target.)
> To my understanding, reinterpret_cast is forbidden in constexpr
> exactly in order to avoid such burdens.
I am not sure if that is the reason, or at least the only reason, why
reinterpret_cast is forbidden in constexpr. As a general point, memory
accesses are very limited in constexpr.
| Paavo Helde <myfirstname@osa.pri.ee>: Apr 29 03:07PM +0300
On 29.04.2016 14:10, David Brown wrote:
> }
> A cross-compiler for embedded ARM devices optimised this to a simple
> "return true;" equivalent.
I hope it got it right (there are ARMs of both endiannesses).
> different target. It will even do so for floating point, getting
> bit-accurate results. (If it can't get bit-accurate results, it falls
> back to generating run-time code for the target.)
Yes, compilers can do very sophisticated optimizations. However, they
are not obliged to do them and as you say they can fall back to leave
some code unoptimized. This is not so with constexpr - if something is
marked constexpr, *all* compiler vendors must implement the needed
functionality and they *cannot* fall back to runtime code generation.
> I am not sure if that is the reason, or at least the only reason, why
> reinterpret_cast is forbidden in constexpr. As a general point, memory
> accesses are very limited in constexpr.
Probably for similar reasons.
Cheers
Paavo
| David Brown <david.brown@hesbynett.no>: Apr 29 02:14PM +0200
On 29/04/16 14:07, Paavo Helde wrote:
>> A cross-compiler for embedded ARM devices optimised this to a simple
>> "return true;" equivalent.
> I hope it got it right (there are ARMs of both endiannesses).
It did. (I have also used gcc for big endian targets, and the compiler
got that right too.)
> Yes, compilers can do very sophisticated optimizations. However, they
> are not obliged to do them and as you say they can fall back to leave
> some code unoptimized.
Correct. If the compiler can't be sure of getting the compile-time
optimisation correct, then it should leave the code as run-time
calculations, and different compilers will vary in how much they can do
at compile time.
> This is not so with constexpr - if something is
> marked constexpr, *all* compiler vendors must implement the needed
> functionality and they *cannot* fall back to runtime code generation.
That is only sort-of correct, I believe. If you are using the constexpr
value as a constant expression (such as for template instantiation, or
the size of a C-style array), then it must be calculated at compile
time. But if the usage of the constexpr code would have been legal C++
without the constexpr, then the compiler /could/ use run-time
calculations - you are not /guaranteed/ compile-time optimisation. And
it is legal to have constexpr functions that contain features that are
only possible at run time, such as "throw" statements, or to call them
using run-time variables. In such cases, there is no way for the
compiler to handle them at compile time - it must be done at run time.
| scott@slp53.sl.home (Scott Lurndal): Apr 29 12:46PM
>> 1977.
>Very interesting, since Unix had very limited usage in 1977 - mainly in
>the educational world. Not even AT&T was using it very much for production.
Interesting, indeed, as I was working for a University on
a PDP-11/34 writing unix drivers for test hardware.
| scott@slp53.sl.home (Scott Lurndal): Apr 29 12:53PM
>I think my first use of unix was in 1978, but I didn't program on it
>until around 1979/1980. When you're young, you don't write these
>things down because who cares? LOL.
What I remember distinctly was how much of a breath of fresh
air Unix was after using TSS/8.24 on the PDP-8.
| scott@slp53.sl.home (Scott Lurndal): Apr 29 12:55PM
>I don't think there was any sort of mechanism for accessing any code
>that wasn't provided as a pascal library or code written in p-code.
><https://en.wikipedia.org/wiki/UCSD_Pascal#UCSD_Pascal_and_the_p-System>
I believe you are correct. We used the Terak machines running UCSD pascal
for a while at the Uni. IIRC, they had a rudimentary IDE.
| ram@zedat.fu-berlin.de (Stefan Ram): Apr 29 07:51AM
>Shouldn't it be up to the compiler to check whether a function or
>constructor is constexpr or not?
The compiler only sees the /declarations/ of library
functions, not the implementations.
In cases where the compiler /can/ see the implementations, a
change in the implementations of those functions then might
turn constexpr functions into non-constexpr functions which
in turn might break client code.
But the most fundamental piece of modern programming is
| ram@zedat.fu-berlin.de (Stefan Ram): Apr 29 08:00AM
Supersedes: <constexpr-20160429085107@ram.dialup.fu-berlin.de>
[added more text at the end]
>Shouldn't it be up to the compiler to check whether a function or
>constructor is constexpr or not?
The compiler only sees the /declarations/ of library
functions, not the implementations.
In cases where the compiler /can/ see the implementations, a
change in the implementations of those functions then might
turn constexpr functions into non-constexpr functions which
in turn might break client code.
But the most fundamental piece of modern programming is
the separation of implementation and interface.
»constexpr« does not only mean that the function is
implemented to be a constexpr function right now, but also
that the publisher avows himself to keep it this way.
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Apr 29 08:57AM +0200
C++11 introduced constexpr for (some) strictly deterministic and
functional code. But now I need to write constexpr at many places in the
code to get the benefits from it.
Shouldn't it be up to the compiler to check whether a function or
constructor is constexpr or not? I mean similar to inline or register
which are no much more than optional hints nowadays. (Yes, I know,
inline implies weak linkage.)
I would prefer when every thing gets constexpr automatically wherever
possible. What should be the motivation to prevent a function to be
constexpr?
I could write a static assertion if I need to check whether an
expression satisfies this constraint. The compiler could do the same
when it requires a constexpr.
In fact this behavior was implemented from the very early days of the C
language as you always could write
int array[3+4];
where 3+4 is nothing else but a constexpr.
So I can't get why there is a need for the new keyword and the resulting
refactoring of library code for C++11 and above.
Marcel
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 29 09:43AM +0200
On 29.04.2016 08:57, Marcel Mueller wrote:
> I can't get why there is a need for the new keyword and the resulting
> refactoring of library code for C++11 and above.
It means the compiler can (and must) tell you wherever you write
`constexpr` code that is beyond what can be `constexpr`, e.g.
inadvertently using dynamic allocation by involving a `std::string`.
So `constexpr` is part of the usual static type checking scheme.
Also, without it checking whether code could be evaluated at compile
time would incur some extra overhead for separate compilation (with
effectively whole program optimization invoked). Today compilers have
whole program optimization as an option. Because it has a cost, in
compilation time, size of object files, and restriction of use of features.
Cheers & hth.,
- Alf
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 29 12:26AM +0100
> http://www.foxnews.com/world/2016/04/28/dutch-dreamer-hopes-to-bring-noahs-ark-replica-to-americas.html?intcmp=hplnws
> I want to give these guys a shout out for their work so far.
> I'm impressed with what they have accomplished.
Looks like a self indulgent vanity project to me.
/Flibble
| Wouter van Ooijen <wouter@voti.nl>: Apr 29 09:35AM +0200
> http://www.foxnews.com/world/2016/04/28/dutch-dreamer-hopes-to-bring-noahs-ark-replica-to-americas.html?intcmp=hplnws
> I want to give these guys a shout out for their work so far.
> I'm impressed with what they have accomplished.
note (from their website) "At 410 feet long, 95 feet wide and 75 feet
high, the ark is half the size of the specifications described in the
Bible. It is made of cedar and pine and was built atop a steel barge ..."
So even at half the size and with modern woodcraft, they didn't try to
built it from wood. It is essentially a big cabin on top of a steel ship.
Note that I live in the Netherlands and I had never heared of this
project. We Dutch don't take religious controversies very serious any
more, otherwise the Dutch would have killed each other centuries ago.
(We did try, but in the end maintaining the Dykes was deemed more
important. Living next to a (different-)religious neighbour is to be
preferred over being dead on the bottom of a sea.)
Wouter "objects? No thanks!" van Ooijen
| Lynn McGuire <lmc@winsim.com>: Apr 28 08:02PM -0500
Is there anything comparing the efficiency of a std::vector with a std::map ? I am using a std::vector in many circumstances with up
to 26,000 entries. Unfortunately, I have very little way of predicting the ultimate size of the vector so I am using push_back () to
add more entries instead of resize ().
I am having some performance issues and am suspecting the std::vector growing so much by a single increments is really slowing my
code down.
Or, should I be using reserve () to increase the size of my std::vector in increments of 10,000 instead of increments of 1 ?
http://en.cppreference.com/w/cpp/container/vector/reserve
Thanks,
Lynn
| Daniel <danielaparker@gmail.com>: Apr 28 06:48PM -0700
On Thursday, April 28, 2016 at 9:02:58 PM UTC-4, Lynn McGuire wrote:
> add more entries instead of resize ().
> Or, should I be using reserve () to increase the size of my std::vector in
> increments of 10,000 instead of increments of 1 ?
You could always reserve 26,000 entries and shrink_to_fit if that turns out
to be excessive.
Also, make sure that the things that you're adding to the vector support
move semantics.
Perhaps try std::deque, but 26,000 doesn't sound to me like a lot of
entries. Make sure that the time to reallocate isn't spent doing copies
rather than moves.
Daniel
| Paavo Helde <myfirstname@osa.pri.ee>: Apr 29 08:31AM +0300
On 29.04.2016 4:02, Lynn McGuire wrote:
> entries instead of resize ().
> I am having some performance issues and am suspecting the std::vector
> growing so much by a single increments is really slowing my code down.
std::vector::push_back() does not grow in single increments, otherwise
it could not be amortized O(1) complexity as required by the standard.
OTOH, insertion and lookup in a map is O(log N), which is much-much worse.
26,000 is a very small number.
IOW, do not try to optimize prematurely. If your program is too slow,
profile it first to find out bottlenecks.
HTH
Paavo
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Apr 29 08:06AM +0200
On 29.04.16 03.02, Lynn McGuire wrote:
> 26,000 entries. Unfortunately, I have very little way of predicting the
> ultimate size of the vector so I am using push_back () to add more
> entries instead of resize ().
You are fine. Using push_back() in a loop with n iterations will not
exceed O(n log n) in total.
> I am having some performance issues and am suspecting the std::vector
> growing so much by a single increments is really slowing my code down.
Use a profiler to track your performance issues. Probably they are
caused by something else.
> Or, should I be using reserve () to increase the size of my std::vector
> in increments of 10,000 instead of increments of 1 ?
> http://en.cppreference.com/w/cpp/container/vector/reserve
If you can approximately predict the upper bound of the size for an
individual vector, reserve() is fine. Otherwise it might be
counterproductive. Allocation too much memory can significantly degrade
cache efficiency, besides the waste of resources, of course.
Note that the situation changes significantly if you use insert()
instead. This yields to O(n²) in general, regardless of reserve().
This is the point where std::map comes into play. But do not expect too
much. std::map uses Red-Black Tree. This is quite ineffective for many
small objects, because of the allocation overhead. This is the price for
keeping iterators valid at insert and delete operations.
If the latter is not required B-Trees with reasonable node sizes (63 or
127) outperform std:map by far. Unfortunately there is no B-Tree in the
std:: namespace.
Marcel
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Apr 29 07:47AM +0200
On 27.04.16 23.45, Ian Collins wrote:
> Do you need pod, or just standard layout?
> If the latter, you could skip the helper and give rPUp constexpr
> constructors, something like
AFAIR members of a union must not contain constructors.
This seems not to be true, it compiles also when rPUp has a constructor.
I wonder how the compiler can handle this. Which constructor should be
invoked when some of the union members have a constructor?
In fact it works somehow. - Puzzled...
Marcel
| "Öö Tiib" <ootiib@hot.ee>: Apr 28 11:01PM -0700
On Friday, 29 April 2016 08:47:15 UTC+3, Marcel Mueller wrote:
> I wonder how the compiler can handle this. Which constructor should be
> invoked when some of the union members have a constructor?
> In fact it works somehow. - Puzzled...
Unions in C++ have changed quite a lot with C++11. See Stroustrup's C++11
FAQ about unions for starters:
http://www.stroustrup.com/C++11FAQ.html#unions
| JiiPee <no@notvalid.com>: Apr 29 12:41AM +0100
On 28/04/2016 22:17, Barry Schwarz wrote:
> definitely not. Do you think
> char* p = k;
> does any kind of copy from the array?
no, but:
char aa[] = "Hello";
*does* copy the hello into it. thats what I mean.... that array is not
"consistant" : sometimes it means copy sometimes it means pointer copy.
But I understand that now....its ok.
| JiiPee <no@notvalid.com>: Apr 29 12:44AM +0100
On 28/04/2016 20:35, Chris Vine wrote:
> void foo(char (&a)[4]) {}
> 'a' retains its quality as a reference to an array of char of size 4,
> and it will refuse to compile if passed a char array of any other size.
interesting.. good to know
| Barry Schwarz <schwarzb@dqel.com>: Apr 28 09:44PM -0700
>*does* copy the hello into it. thats what I mean.... that array is not
>"consistant" : sometimes it means copy sometimes it means pointer copy.
>But I understand that now....its ok.
Your declaration above is not an assignment, despite what it looks
like. It is initialization.
And the same "inconsistency" applies to initialization. Your
declaration will copy data while
char *bb = "Hello";
will not.
--
Remove del for email
|
Jerry Stuckle <jstucklex@attglobal.net>: Apr 28 03:28PM -0400
On 4/27/2016 9:33 PM, Öö Tiib wrote:
>> Yup, when you use the gcc compiler and tools.
> Jerry, you go too far here in that denial. The 'ar' is Unix utility
> (pretty much like 'tar') and not some sort of gcc tool.
Which does not mean that other tools can't include their own versions of
library creation tools.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 28 03:29PM -0400
On 4/28/2016 12:21 AM, Ian Collins wrote:
>>> incompatibilities.
>> It does if you use the ar from the appropriate toolkit.
> The only "toolkit" ar comes from is the operating system.
Which does not prohibit another toolkit from having their own version.
I find it interesting that Linux programmers, who spend virtually all
their time with one OS and one compiler, think the entire world works
that way.
It doesn't, as people who work on multiple OS's and with multiple
compilers understand.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 28 03:32PM -0400
On 4/28/2016 9:57 AM, Scott Lurndal wrote:
>> Believe I've been working with unix for probably a lot longer than you
>> have - back around 1979 (although not continuously since that time)
> 1977.
Very interesting, since Unix had very limited usage in 1977 - mainly in
the educational world. Not even AT&T was using it very much for production.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 28 03:48PM -0400
On 4/28/2016 4:13 AM, David Brown wrote:
> calling conventions for libraries? How would printf work? (Variable
> argument functions are easily handled with C calling conventions, but
> not with Pascal conventions.)
Functions like printf are part of the C library, so of course they use C
calling conventions. You don't call them from PASCAL or COBOL, for
instance.
But non-C derived languages such as FORTRAN and COBOL do not use C
calling conventions.
And BTW - Windows is written in C, also. So are the Windows libraries.
But the calling convention into the system libraries is not C.
> world (and its DOS predecessor) where there is a jumble of local
> conventions, often designed specifically for vendor lock-in rather than
> cooperation.
Yes, there are many different OS's. But if you want to be able to use
languages such as Fortran and Cobol, the OS libraries need to use
calling conventions supported by those languages.
> Yes, there have been other Pascals. But the users of Delphi and its
> predecessors Borland Pascal and Turbo Pascal probably outweigh the
> combined number of users for every other Pascal by a factor of a hundred.
Once again, your ignorance shows. For one thing, there were millions of
students around the world using UCSD Pascal in the late 70's and early
80's - ling before Delphi, Borland Pascal, and so on. It was a common
language taught in many universities.
But beyond that, large and medium companies (including IBM) used Pascal
extensively in the 1980's. But they were using enterprise grade
products, not Delphi.
> calling conventions. I don't know what calling conventions were used on
> UCSD P-code systems - I was perhaps 9 or 10 when I used that on a VAX,
> and did not get far beyond a "Hello, world" program.
The calling conventions were similar, for those machines which had a
hardware stack. For those without one, values were placed in a
"parameter passing area" and the address of that area placed in a register.
> a total confidence even when your claims are pure fantasy, and everyone
> around you is laughing. I am sure you would make an excellent poker
> player, but I am very glad I don't have to deal with you professionally.)
No, the difference is your "knowledge", AFAICT, is based pretty much on
one set of tools on one OS. And you think the rest of the world works
that way.
> way to do it - but that would only give you limited capabilities. In
> particular, to be really useful, you need the endianness to be testable
> in the preprocessor.
Just a question - a problem similar to what consultants have to solve on
a regular basis. Just seeing if you really knew what you were talking
about. I see you don't.
> Certainly I will publicise your success in c.l.c and c.l.c++, and it
> will be seen even by the many people who have killfiled you. If not,
> then your reputation - low as it is - will drop further.
Yes, I raised the challenge. It's up to you to solve it. I have
(actually did several years ago). Come on, David, give it a go.
Or do you need someone to hand feed you everything?
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
| Ian Collins <ian-news@hotmail.com>: Apr 29 08:11AM +1200
On 04/29/16 07:29, Jerry Stuckle wrote:
>>> It does if you use the ar from the appropriate toolkit.
>> The only "toolkit" ar comes from is the operating system.
> Which does not prohibit another toolkit from having their own version.
Name one.
> I find it interesting that Linux programmers, who spend virtually all
> their time with one OS and one compiler, think the entire world works
> that way.
I'm not a Linux programmer.
--
Ian Collins
| Paavo Helde <myfirstname@osa.pri.ee>: Apr 28 11:28PM +0300
On 28.04.2016 22:48, Jerry Stuckle wrote:
> Just a question - a problem similar to what consultants have to solve on
> a regular basis.
I think we really do have a highly-paid consultant here! And he
routinely solves the unsolvable problems! Why don't we just sit all back
in awe and watchen das blinkenlights?
As for solving the endianness problem, the practical solution (as
opposed to "complete, portable and standard-conforming solution") is
indeed really simple:
#include <boost/detail/endian.hpp>
#if defined(BOOST_LITTLE_ENDIAN)
const bool bigEndian = false;
#elif defined(BOOST_BIG_ENDIAN)
const bool bigEndian = true;
#else
#error Unsupported platform.
| | |
