User avatar
Paeryn
Posts: 2565
Joined: Wed Nov 23, 2011 1:10 am
Location: Sheffield, England

Re: Solution to X-Toolkit and portability.

Sun Nov 20, 2016 3:19 am

It's the language that defines it. What compiler do you use that doesn't follow? And could ypu give a small working example to see how they implentated it with breaking other things?
She who travels light — forgot something.

Heater
Posts: 12657
Joined: Tue Jul 17, 2012 3:02 pm

Re: Solution to X-Toolkit and portability.

Sun Nov 20, 2016 4:26 am

DavidS,
Why should I have to look at a header file to figure out what the currently set values of the constants are.
Obviously constants are defined in separate files because they can be used in many other files. Especially true of constants used in libraries and operating system API's where they arg used by many other programs on your machine and millions of other machines around the world.

If you had to write them into every source file that used them it would be chaos.

I do agree that is is sometimes annoying to find the header of a header of a header... to find a definition. It's not often one needs to though.
Though I am guessing that you do not believe in the short source file, based on your like of digging through headers?
Who said I like digging anything?

I have no hard opinion on the length of source files or functions.

Obviously extremes of too short or too long become an impractical, unwieldy mess.

Rather than have arbitrary rules about it I feel one should just be sensible. Don't mix up a bunch of functionality into a single function. Break things down into meaningful parts. Don't fill files up with unrelated things. On the other hand splitting up a function just because it's more than 7 lines long, or whatever your limit is, just makes things less comprehensible.

Note: I have heard people suggest a limit of 7 lines per function. Recently a guy gave a presentation on OOP design and said we should aim for only 3 lines!

Rather than fretting about length of files and functions it's better to try and decouple them as much as possible. Having every file depend on every other file in a project is a maintenance and testing nightmare. If you have too much coupling/dependence between files you may as well sling it all in one huge file!

The architect Louis Sullivan said "Form Follows Function". When architecting software I feel it should be "function follows form" :)
Last edited by Heater on Sun Nov 20, 2016 5:05 am, edited 1 time in total.

Heater
Posts: 12657
Joined: Tue Jul 17, 2012 3:02 pm

Re: Solution to X-Toolkit and portability.

Sun Nov 20, 2016 5:03 am

DavidS,
If those are the limits imposed by GCC that would explain why some of my code does not work.
I'm pretty certain that is not a limit imposed by GCC and that your code is not actually C++ as defined in 1985 or standardized in 1998.
To bad that C++ was not standardized before many were already using it, and the differences in implementation had already spread to the point that the standard is nearly meaningless.
Nonsense. Certainly there were annoying differences between C++ compilers, usually minor, usually missing features that had not been implemented yet. But for nearly two decades I have found it possible to create C++ code than works across GCC, Visual C++, and a few others.

Today we have GCC, Clang/LLVM, Visual C++ and others that are very standards compliant. The standard is far fro meaningless.

Now, what compiler are you using? On what platform? And can you provide a minimal example of source that overrides operators without using classes or enumeration types?

This could of course be another one of the billion things I do not know about C++ :)
Last edited by Heater on Sun Nov 20, 2016 10:06 am, edited 1 time in total.

User avatar
DavidS
Posts: 4220
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Solution to X-Toolkit and portability.

Sun Nov 20, 2016 5:40 am

As to the operater overloading, this works with the C++ compiler I most recently used for my C code, and have used since the late 1980's (forgive any error as I am not at the computer the compiler runs on):

Code: Select all

#include <string.h>
#include <stdio.h>

//Overload the assignment operator for strings, and keep it local to current file.
static char *operator=(char *dest,char *source){
 strcpy(dest,source);
 return dest;
}

void main(void){
  char hello[13];
  
  hello = "Hello World";
  puts(hello);
  
  return;
}
The example is kind of contrived, though I wanted to make sure that it was as correct as I could without booting an Atari to compile it.

The compiler runs on the Atari ST/STE/TT/Falcon and other computers running Atari TOS or compatible Operating Systems, it is named cppc.prg and it takes in C++ code and spits out C code that can be compiled with any normal C compiler. The latest version that I have is able to output 100% ANSI C89 compliant code.

I generaly do not deal with C or C++, and when I do I tend to do things as they work on the C++ compiler that I know and often use.

NOTE: Just tested and this does NOT work with gcc, which explains many of the errors I could never figure out.

NOTE 2: As is obvious overloading an operator using a base type prevents the use of that operator in the normal way with that base type. So in this example if you wanted to do direct pointer assignment with pointer to type char in that file you can not (unles you did so with the += operator or similar). So it is a be careful situation.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
jojopi
Posts: 3077
Joined: Tue Oct 11, 2011 8:38 pm

Re: Solution to X-Toolkit and portability.

Sun Nov 20, 2016 6:40 am

Your original example used a struct that mirrored the icon block argument to RISC OS system call WIMP_CreateIcon.

Are you now claiming that you "always" translate your non-C++ to C on an Atari platform, prior to compiling it on RISC OS?

ejolson
Posts: 3060
Joined: Tue Mar 18, 2014 11:47 am

Re: Solution to X-Toolkit and portability.

Sun Nov 20, 2016 7:30 am

DavidS wrote:The compiler runs on the Atari ST/STE/TT/Falcon and other computers running Atari TOS or compatible Operating Systems, it is named cppc.prg and it takes in C++ code and spits out C code that can be compiled with any normal C compiler.
Have you tried installing the aranym Raspbian package to see if it's possible to run this cppc.prg C++ to C translator in the Atari emulator on a Pi? Maybe the C output could then be fed into the native gcc compiler on the Pi.

Heater
Posts: 12657
Joined: Tue Jul 17, 2012 3:02 pm

Re: Solution to X-Toolkit and portability.

Sun Nov 20, 2016 10:25 am

I'm not sure that the problems with some buggy C++ preprocessor from 30 years ago for a language that was in it infancy at the time and not standardized until after the platform it runs on was discontinued 20 years ago is grounds for saying the C++ standard we have had for nearly two decades is "meaningless".

I'm not sure what the purpose of overloading the "=" operator for strings is here. It means you always end up copying the string rather than just getting a new pointer to it, which is inefficient. It is as unsafe as the strcpy it is trying to avoid, do you know the destination has enough room for the string? Better would be just to create a simple String class to encapsulate strings and make them robust.

Mind you, I loved my Atari 520ST and 1040ST. Wish I still had them. And the highres monochrome Atari monitor.

jahboater
Posts: 4440
Joined: Wed Feb 04, 2015 6:38 pm

Re: Solution to X-Toolkit and portability.

Sun Nov 20, 2016 10:47 am

Sorry, I know this thread has moved on to the benefits of 30 year old C++ compilers, but this might be interesting.
ejolson wrote: This either means that the loop is optimal or the library is not. Is 1688 MB/s the correct memory bandwidth for the Pi 3? Roylongbottom claims the Pi 3 has a double-pumped DDR2 memory bus speed of 900 MHz with a bus width of 4 bytes for a theoretical bandwidth of 7200 MB/s.
I think thats (450Mhz * 2) * 4 which is 3600 MB/s.

Here are some memory timings for a Pi3 at stock speeds. 1688 MB/s seems reasonable.

Code: Select all

==========================================================================
== Memory bandwidth tests                                               ==
==                                                                      ==
== Note 1: 1MB = 1000000 bytes                                          ==
== Note 2: Results for 'copy' tests show how many bytes can be          ==
==         copied per second (adding together read and writen           ==
==         bytes would have provided twice higher numbers)              ==
== Note 3: 2-pass copy means that we are using a small temporary buffer ==
==         to first fetch data into it, and only then write it to the   ==
==         destination (source -> L1 cache, L1 cache -> destination)    ==
== Note 4: If sample standard deviation exceeds 0.1%, it is shown in    ==
==         brackets                                                     ==
==========================================================================

 C copy backwards                                     :   1166.6 MB/s (0.7%)
 C copy backwards (32 byte blocks)                    :   1161.8 MB/s (0.8%)
 C copy backwards (64 byte blocks)                    :   1162.7 MB/s (0.8%)
 C copy                                               :   1167.1 MB/s (0.8%)
 C copy prefetched (32 bytes step)                    :   1199.5 MB/s
 C copy prefetched (64 bytes step)                    :   1200.2 MB/s (1.2%)
 C 2-pass copy                                        :    951.5 MB/s
 C 2-pass copy prefetched (32 bytes step)             :    972.9 MB/s (1.1%)
 C 2-pass copy prefetched (64 bytes step)             :    967.6 MB/s
 C fill                                               :   1574.4 MB/s (0.3%)
 C fill (shuffle within 16 byte blocks)               :   1575.9 MB/s (0.5%)
 C fill (shuffle within 32 byte blocks)               :   1575.7 MB/s (0.5%)
 C fill (shuffle within 64 byte blocks)               :   1575.7 MB/s (0.4%)
 ---
 standard memcpy                                      :   1186.7 MB/s (0.8%)
 standard memset                                      :   1575.3 MB/s (0.4%)
 ---
 NEON read                                            :   1975.3 MB/s (1.0%)
 NEON read prefetched (32 bytes step)                 :   2126.6 MB/s (1.0%)
 NEON read prefetched (64 bytes step)                 :   2126.7 MB/s (1.5%)
 NEON read 2 data streams                             :   1862.3 MB/s
 NEON read 2 data streams prefetched (32 bytes step)  :   2119.6 MB/s
 NEON read 2 data streams prefetched (64 bytes step)  :   2120.2 MB/s (1.6%)
 NEON copy                                            :   1156.7 MB/s (0.9%)
 NEON copy prefetched (32 bytes step)                 :   1195.8 MB/s
 NEON copy prefetched (64 bytes step)                 :   1194.4 MB/s (0.8%)
 NEON unrolled copy                                   :   1169.9 MB/s (1.5%)
 NEON unrolled copy prefetched (32 bytes step)        :   1190.4 MB/s (1.2%)
 NEON unrolled copy prefetched (64 bytes step)        :   1171.4 MB/s (1.0%)
 NEON copy backwards                                  :   1163.3 MB/s (1.2%)
 NEON copy backwards prefetched (32 bytes step)       :   1193.0 MB/s
 NEON copy backwards prefetched (64 bytes step)       :   1192.8 MB/s (1.2%)
 NEON 2-pass copy                                     :    966.2 MB/s (1.6%)
 NEON 2-pass copy prefetched (32 bytes step)          :   1002.6 MB/s (1.2%)
 NEON 2-pass copy prefetched (64 bytes step)          :    999.1 MB/s (1.0%)
 NEON unrolled 2-pass copy                            :    948.1 MB/s
 NEON unrolled 2-pass copy prefetched (32 bytes step) :    963.7 MB/s
 NEON unrolled 2-pass copy prefetched (64 bytes step) :    964.7 MB/s (0.9%)
 NEON fill                                            :   1576.9 MB/s (0.4%)
 NEON fill backwards                                  :   1575.9 MB/s (0.5%)
 VFP copy                                             :   1166.6 MB/s (0.7%)
 VFP 2-pass copy                                      :    941.4 MB/s (0.8%)
 ARM fill (STRD)                                      :   1575.4 MB/s (0.3%)
 ARM fill (STM with 8 registers)                      :   1576.9 MB/s (0.5%)
 ARM fill (STM with 4 registers)                      :   1576.2 MB/s (0.5%)
 ARM copy prefetched (incr pld)                       :   1196.4 MB/s
 ARM copy prefetched (wrap pld)                       :   1195.0 MB/s (1.2%)
 ARM 2-pass copy prefetched (incr pld)                :    977.4 MB/s (1.1%)
 ARM 2-pass copy prefetched (wrap pld)                :    973.9 MB/s (0.2%)
Last edited by jahboater on Sun Nov 20, 2016 11:01 am, edited 1 time in total.

tufty
Posts: 1456
Joined: Sun Sep 11, 2011 2:32 pm

Re: Solution to X-Toolkit and portability.

Sun Nov 20, 2016 10:53 am

DavidS wrote:With every compiler on RISC OS so far those assumptions are always true, and the target is RISC OS, nothing else.
Well, forgive me for thinking that, in a thread entitled "Solution to X-Toolkit and portability", you might be interested in - well - portability.

FWIW, nothing in your post with its code examples explicitly said RiscOS, it was all about your insane vendetta against all things modern. Modern Coding Style, Modern Compilers, Modern Assembler Notation, Modern Programming Languages, Modern Techniques, Modern Operating Systems, it's all wrong, no?

As for your source-to-source C++ compiler, if you're lucky, it's based on CFront, and at a guess no more than version 2. If so it'll handle (with a load of caveats) C++ circa 1990 or so at best, which is not a valid starting point for criticising the language. I'd be interested to see what copyrights it puts out if you ask it for information, assuming you can do that.
Last edited by tufty on Sun Nov 20, 2016 11:21 am, edited 1 time in total.

Heater
Posts: 12657
Joined: Tue Jul 17, 2012 3:02 pm

Re: Solution to X-Toolkit and portability.

Sun Nov 20, 2016 11:11 am

I think DavidS is right. The modern world sucks. Things were indeed much better 30 or so years ago.

Things were much better in the world of computing when one had to toggle a bunch of switches on a front panel to get the computer booted up. Better when we had to then load programs from paper tape or punched cards. That was great because we had computer operators who did all that for us.

Those operators also did all the tedious loading of paper to printers and so on.

Things we much better when we wrote our code on coding sheets. You know, actual writing by hand. That was great because we had secretarial pools full of young girls who could do all that tedious typing for us and get the tapes/cards punched.

Things were much better before we had compilers. One could write code in a high level language, say ALGOL. Then compile that into assembler manually. Then assemble that to hex codes, manually. Then give it to the girls for punching. That was great because one then had complete control of every byte in ones program.

Back in the day only a few percent of people got degrees, let alone technical ones. There was almost no such thing as a CS degree. So if one knew anything about computers and coding at all one commanded much respect.

Believe it or not I have studied and/or worked in environments where all of the above has been true.

So trust me. I know. Things were much better then.
Last edited by Heater on Sun Nov 20, 2016 11:46 am, edited 1 time in total.

jahboater
Posts: 4440
Joined: Wed Feb 04, 2015 6:38 pm

Re: Solution to X-Toolkit and portability.

Sun Nov 20, 2016 11:25 am

Heater wrote:Things were much better in the world of computing when one had to toggle a bunch of switches on a front panel to get the computer booted up.
You mean loading the first few instructions into the machine - in binary with 16 switches. We had a machine like that once, it also had "real" ferrite core memory.
Heater wrote:Things we much better when we wrote our code on coding sheets. You know, actual writing by hand. That was great because we had secretarial pools full of young girls who could do all that tedious typing for us and get the tapes/cards punched.
Definitely!

Mechanical things are limited in complexity to a few hundred moving parts.

Electrical hardware is limited to a billion or so transistors or gates.

Software is limited in complexity only by humans ability to manage it.

In the days of mercury delay lines, programs were nice and small and easy to understand!
Not so now when the average PC has 8GB or more of memory.

User avatar
PeterO
Posts: 4727
Joined: Sun Jul 22, 2012 4:14 pm

Re: Solution to X-Toolkit and portability.

Sun Nov 20, 2016 11:48 am

For some of us those days are not just a distant memory :-)
https://www.youtube.com/watch?v=AIxZ1i8pvZI
https://www.youtube.com/watch?v=Wa7KVU_e8U8

PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

Heater
Posts: 12657
Joined: Tue Jul 17, 2012 3:02 pm

Re: Solution to X-Toolkit and portability.

Sun Nov 20, 2016 12:11 pm

jahboater,

Yes, just like that. Switches and blinky lights. How can you have a computer without lots of switches and blinky lights?

We replaced a machine like that only about 10 years ago. It was a Data General Nova managing all the traffic lights in Helsinki. Wonderful thing.
Software is limited in complexity only by humans ability to manage it.
Can I be weird and suggest that may not be true?

Seems to me that computers and/or their software exceeded our ability to manage it ages ago. But still it keeps growing and spreading.

Software is some kind of life form in it's own right. It grows and reproduces. It mutates and cross-breeds. It evolves and adapts to new niches all the time. IoT anyone?

We like to think we create it and control it. In reality we are well past that point. We are just the building blocks or mechanism, the substrate, on which this life form feeds. We are to software what that soup of organic chemicals is to the carbon based life forms that sprang from it.
In the days of mercury delay lines, programs were nice and small and easy to understand!
That might not be true either. Google for "The Story Of Mel" to see why.

jahboater
Posts: 4440
Joined: Wed Feb 04, 2015 6:38 pm

Re: Solution to X-Toolkit and portability.

Sun Nov 20, 2016 12:24 pm

Heater wrote:We replaced a machine like that only about 10 years ago. It was a Data General Nova managing all the traffic lights in Helsinki. Wonderful thing.
Last time I saw a Data General Nova it was built into the console of a large Amdahl mainframe.
Heater wrote:Google for "The Story Of Mel" to see why.
That's a great story! Someone in this thread should read it ...

jahboater
Posts: 4440
Joined: Wed Feb 04, 2015 6:38 pm

Re: Solution to X-Toolkit and portability.

Sun Nov 20, 2016 12:30 pm

Heater wrote: Yes, just like that. Switches and blinky lights. How can you have a computer without lots of switches and blinky lights?
And sound effects. I am guessing some of the sound in PeterO's first presentation was a speaker attached to the data bus or something similar? I know very old ICL mainframes could be monitored by their sound.

User avatar
DavidS
Posts: 4220
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Solution to X-Toolkit and portability.

Sun Nov 20, 2016 12:53 pm

FWIW, nothing in your post with its code examples explicitly said RiscOS, it was all about your insane vendetta against all things modern. Modern Coding Style, Modern Compilers, Modern Assembler Notation, Modern Programming Languages, Modern Techniques, Modern Operating Systems, it's all wrong, no
I have no problem with modern styles, as long as they are readable, Heaters examples for point are great.

I also have nothing against modern languages, not one bit.
s for your source-to-source C++ compiler, if you're lucky, it's based on CFront, and at a guess no more than version 2. If so it'll handle (with a load of caveats) C++ circa 1990 or so at best, which is not a valid starting point for criticising the language.
Slow down there. I never critisized the language, not one bit.

It is just frustrating that there are significant differences in code that was written for different compilers before the language was standardised. And there is a lot of C++ that was written before the language was standardized.
I'd be interested to see what copyrights it puts out if you ask it for information, assuming you can do that.
No such information. I think that this one was written by verious people at the school I attended at the time, may be wrong. Though I got it by it being passed around at school, and improved on every week for a few years.

I have an (admitedly old) document on the C++ language that says that all operators can be overloaded, and that while any type may be used in overloading it is recomended to use different lhs and rhs values OR use a user defined type.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
DavidS
Posts: 4220
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Solution to X-Toolkit and portability.

Sun Nov 20, 2016 12:54 pm

jojopi wrote:Your original example used a struct that mirrored the icon block argument to RISC OS system call WIMP_CreateIcon.

Are you now claiming that you "always" translate your non-C++ to C on an Atari platform, prior to compiling it on RISC OS?
Only when I write in C++, which is very rare.
Last edited by DavidS on Sun Nov 20, 2016 1:33 pm, edited 1 time in total.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
DavidS
Posts: 4220
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Solution to X-Toolkit and portability.

Sun Nov 20, 2016 12:56 pm

tufty wrote:
DavidS wrote:With every compiler on RISC OS so far those assumptions are always true, and the target is RISC OS, nothing else.
Well let us see, it uses a RISC OS WIMP Icon structure, and calls Wimp_CreateIcon, I wonder what OS it could possibly be for.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
PeterO
Posts: 4727
Joined: Sun Jul 22, 2012 4:14 pm

Re: Solution to X-Toolkit and portability.

Sun Nov 20, 2016 1:00 pm

jahboater wrote:And sound effects. I am guessing some of the sound in PeterO's first presentation was a speaker attached to the data bus or something similar? I know very old ICL mainframes could be monitored by their sound.
The speaker on the 803 is connected to the top bit of the instruction register. And the ICL 2966 at TNMOC can be heard warbling away as well :-)
PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

User avatar
DavidS
Posts: 4220
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Solution to X-Toolkit and portability.

Sun Nov 20, 2016 1:03 pm

Heater wrote:I think DavidS is right. The modern world sucks. Things were indeed much better 30 or so years ago.
I dissagree, I prefer the modern tools and languages. Let us be real, please.
Things were much better in the world of computing when one had to toggle a bunch of switches on a front panel to get the computer booted up. Better when we had to then load programs from paper tape or punched cards. That was great because we had computer operators who did all that for us.

Those operators also did all the tedious loading of paper to printers and so on.

Things we much better when we wrote our code on coding sheets. You know, actual writing by hand. That was great because we had secretarial pools full of young girls who could do all that tedious typing for us and get the tapes/cards punched.

Things were much better before we had compilers. One could write code in a high level language, say ALGOL. Then compile that into assembler manually. Then assemble that to hex codes, manually. Then give it to the girls for punching. That was great because one then had complete control of every byte in ones program.

Back in the day only a few percent of people got degrees, let alone technical ones. There was almost no such thing as a CS degree. So if one knew anything about computers and coding at all one commanded much respect.

Believe it or not I have studied and/or worked in environments where all of the above has been true.

So trust me. I know. Things were much better then.
Now you are being rediculouse. We have all worked with punch tape, front pannel switches, etc, nothing special about that.

Though we live in 2016, and modern programming is great. And it is my preference. Though that is GOOD MODERN PROGRAMMING. If people can actually read the code.

My only frustration is with unreadable code. You make statements about not needing to know the value of constants, how can you not need to know the value of constants? Not looking at them is worste indeed than a Trust Attack. At least with a Trust Attack the compiler is hiding it from you, with incorect constant values when calling an OS or library things can go very wrong.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
DavidS
Posts: 4220
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Solution to X-Toolkit and portability.

Sun Nov 20, 2016 1:05 pm

As about half the posts have switched over to attempting to put words into my mouth that never came out of it, and making false accusations about what I am talking about or how I like programming I am out of this thread.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

Heater
Posts: 12657
Joined: Tue Jul 17, 2012 3:02 pm

Re: Solution to X-Toolkit and portability.

Sun Nov 20, 2016 1:15 pm

DavidS,
...Heaters examples for point are great.
Why thank you. I like to keep things clear and simple because, well, I'm simple.
...I never critisized the language, not one bit.
Hmmm...saying that the standard for the language that has been in place for two decades and adhered to by many is "meaningless" could well be construed as a criticism of the language. Don't you think?

Mind you. I think there is a lot to criticize in C++. Huge, complex, thing that no single person can possibly understand in it's entirety that it is.
It is just frustrating that there are significant differences in code that was written for different compilers before the language was standardised. And there is a lot of C++ that was written before the language was standardized.
Oddly that is not a problem for 99.999% of the programming population.

But, such is the nature of standards. It's better than existing good practice and ideas that are tried and tested are standardized rather than have some standards committee dream up some unusable ideas and dictate it as a standard. Of course that means that not every ones practice gets into the standard. Hopefully. Choices have to be made.
I have an (admitedly old) document on the C++ language that says that all operators can be overloaded, and that while any type may be used in overloading it is recomended to use different lhs and rhs values OR use a user defined type.
Interesting. What is this document called? Who wrote it? Any links to it online? Any chance of a scan/photo of such paragraphs.

User avatar
DavidS
Posts: 4220
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Solution to X-Toolkit and portability.

Sun Nov 20, 2016 1:22 pm

Though before I step out of this thread:
@Heater:
Thank you Heater for the constructive debate. I have actually learned a good bit. And I am less likely to use veriable/identifier names that omit vowels.

Though I will still use short readable names for Identifiers and constants, as it just makes code more readable.

You have also pointed out a great solution to the problem of multi source constants, in that simply including a comment about where which constants are defined at the head of the source file would take care of that.

Debating with you is always a good learning experience.

Unfortunately some of the comments by others are rather destructive. It almost seems as if some wish to push me and others awayfrom using C/C++/JS/etc.

Though your contributions are always of great value, even if I dissagree.

I know that I should probably learn what has changed with C++, though I have yet to find a C++ compiler for modern systems that does not take forever to compile anything.

It is interesting that a thread about a modern form of the BASIC Programming language ended up about C/C++ and coding styles, though that is how things go.

And before I go, Heater I think you will like another very good quote that I agree with, this one by Henk Robbers:
I hate:
        local prefixes,
        propagating parts of structure names in member names,
        adopting part of  redefined type in typedef name,
        names that try too hard to describe what they name,
        mixed case in names.

    You have:  current professional standards
                          and real professional standards.
    I try to exercise the latter as a hobby.    :-)
You have a greate day, and I look forward to our next constructive debate. Hopefuly next time no negitive missunderstandings get inserted by others.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

Heater
Posts: 12657
Joined: Tue Jul 17, 2012 3:02 pm

Re: Solution to X-Toolkit and portability.

Sun Nov 20, 2016 2:24 pm

It's all good stuff DavidS.

Of course you will never get two programmers, professional or otherwise to agree on code formatting or language choice or best editor, operating system, etc, etc.

Never heard of Henk Robbers. Had to check.

Seems like a clever chap.

Mind you I would never agree to what he has done in C in his TINYCALC. For example he has defined things like "esac" to end case clauses with. And "eq" where "==" would do. Worse still they are not defined in a header file but in what looks like some obscure build file.

Anyway, I learned something here:

One can indeed do operating overloading in C++ without involving a class. One can do it with enumeration types. But not for the assignment operator. And there is the typical collection of a thousand rules and exceptions about operating overloading that make my head explode. I don't believe anyone knows all of the rules in C++.

User avatar
Paeryn
Posts: 2565
Joined: Wed Nov 23, 2011 1:10 am
Location: Sheffield, England

Re: Solution to X-Toolkit and portability.

Sun Nov 20, 2016 2:57 pm

DavidS wrote:I have an (admitedly old) document on the C++ language that says that all operators can be overloaded, and that while any type may be used in overloading it is recomended to use different lhs and rhs values OR use a user defined type.
I found a section in a book by Stroustrup about how C++ evolved between 1985 and 1989,
To avoid nasty inconsistencies between the predefined operator=() functions and user defined operator=() functions, operator=( ) must be a member function. Global assignment functions such as ::operator=(X&, const x&) are anachronisms and will be disallowed after a decent interval.
So for at least 27 years (2-6 years after the language first appeared) it's been deemed something that shouldn't be done because it causes problems when = suddenly starts behaving inconsistently. I don't think overloading operators was ever intended to override how they worked on built in types, it was deprecated in the second version of C++ and had been invalidated by the time it was first standardised.

Oh, and if you document says that all operators can be overloaded then it refers to a wholly nonconformant C++ compiler, there are ten operators (that I can think of) that have never been able to be overloaded in any way whatsoever in any version.
She who travels light — forgot something.

Return to “Other programming languages”