Topic: ADUG Perth Meeting - Regroup, Talk, and Planning
Thursday 8th February 2024
6:00pm Meeting open (Perth) … 9pm Eastern time (DST)
6:15pm Presentations start
Presenter - Scott Hollows
Topic - Grab bag of Delphi tips and techniques
Tips and reviews of Delphi code features and quirks based on Scott’s work in Delphi over the past year. It would be nice to have some kind of theme going here, but the closest thing to that is “there is no moral to this story, its just a bunch of stuff that happened” (quote from the Simpsons, lawyer explaining their court defence to a judge) - so random interesting Delphi stuff
As a fun side topic, Scott has been involved in the Technology Museum of WA and will provide an update on what the museum is doing and how you can get involved.
Scott has been involved in the Delphi world since its predecessor Turbo Pascal developing a wide range of applications and helping out on the WA and national committees of ADUG.
[Editor Stan Lee here :
Wow, that is quite the understatement, Buckaroo. Ok, I’m out, true believers. Excelsior! ]
During our February meeting, when @scott.hollows was making a point about const [ref] with regard to inheritance and function parameters, I made a mildly successful attempt to explain how C++ can deal with these issues.
I thought I could do a better job in a few minutes, and just record a better explanation
… instead I have a long, slow battle with my cranial archive to remember stuff I have figured out in the past.
The end result is much longer than I planned, and of limited interest … but for what its worth, here it is :
#include <iostream>
/*
C++ has high granularity of its specification of constness around values and pointers
- value
- constant value
- pointer to a value
- pointer to a constant value
- constant pointer to a (changeable) value
- constant pointer to a constant value
*/
int i = 1;
int j = 2;
const int k = 42;
int* pi = &i; // a pointer to int, can be changed
const int * cpi = &i; // the pointer CAN be changed
// the TARGET CANNOT be changed
int* const kpi = &i; // the pointer CANNOT be changed
// the TARGET CAN be changed
const int* const xi = 0; // the pointer CANNOT be changed
// the TARGET CANNOT be changed
int main()
{
i = 5; // {normal integer can be changed}
i = 10;
//k = 1; error {error - const int cannot be changed}
std::cout << "\n";
std::cout << "1. Plain pointer pi can be changed, as expected \n";
std::cout << "\n " << pi << "\n";
pi = &j;
std::cout << "\n " << pi << "\n\n";
pi = &i;
std::cout << "3. Plain pointer pi 's target can be changed, as expected \n";
std::cout << "\n " << *pi << "\n";
*pi = 11;
std::cout << "\n " << *pi << "\n\n";
std::cout << "4. (Const int)* pointer = 'Pointer to a Constant Integer' \n\n";
std::cout << " (Const int)* pointer cpi 's pointer can be changed ... OK \n";
std::cout << " (Const int)* pointer cpi 's target cannot be changed ... OK \n";
cpi = &i;
std::cout << "\n " << *cpi << "\n";
//*cpi = 100; {error - const int* target cannot be changed}
std::cout << "\n " << *cpi << "\n\n";
std::cout << "5. (int)* const pointer = 'Constant Pointer to a (mutable) Integer' \n\n";
std::cout << " (int)* const pointer kpi 's pointer cannot be changed ... OK \n";
std::cout << " (int)* const pointer kpi 's target can be changed ... OK \n";
std::cout << "\n " << *kpi << "\n";
//kpi = &i; {error - int* const pointer cannot be reassigned}
*kpi = 100;
std::cout << "\n " << *kpi << "\n\n";
std::cout << "6. (Const int)* const pointer = 'Constant Pointer to a Constant Integer' \n\n";
/*
Notes :
1. If I knew what I was doing before I started,
I should have called 'cpi' as 'pci', ie 'pointer to constant integer'.
2. While a 'pointer to const' can give some protection of an integer value,
If the target is a normal, mutable integer ...
then the target can be changed by other parts of the program.
3. Only a 'pointer to const' can be assigned the address of a constant integer.
It can be assigned to a normal integer, and no changes can be effected via that pointer.
4. The whole "East Const" vs "West Const" rivalry is based on the nutbag idea that, assuming reading types from right to left is what real programmers do, then ``` int const * ``` and ``` int * const ``` read slightly more sanely that wsy. But bear in mind, it's the sanity of C+× programmers that we are talking here, so ... 🤨 😅
*/
getchar();
}
WADUG Perth Meeting - ONLINE - Tue 12th March 2024. 6pm AWST
Hello everyone.
There’s a lot going on in the Delphi arena.
Officially online meeting, Tuesday night at 6pm. See below for the link.
Hopefully we will get to hear from Peter Thonell about designing a Realtime Strategy Game, but if there’s a schedule issue, we still have a full plate of topics.
Registrations are now open for The ADUG Symposium 2024. 4 great speakers, including Mark Fletcher (in my industry) who has an extensive Point of Sale software system, started back in the 1990s.
Thanks all,
Hope to see you online tonight.
Paul McGee
Registrations are now open for The ADUG Symposium 2024. 4 great speakers, including Mark Fletcher (in my industry) who has an extensive Point of Sale software system, started back in the 1990s.
the developing Linux xz backdrop drama (sure to become a novel),
a purpose-design facility from which we hope WADUG will be joining the symposium this year, AND
the Delphi 12.1 release … and current (somewhat encouraging?) Embarcadero vibes.
We had a really great demonstration and explanation of RTTI and Attributes by Scott van der Linden, which speaking personally gave me a much better idea about how the Classes that define attributes interact conceptually with the Classes, fields, properties, etc of the “bare” objects and data structures of a program / unit.
ie how it adds to the RTTI information cloud around a given data structure … and he demonstrated using, among other examples, DUnitX to point out how the procedures under test, and the Attributes defined, then become the input to the framework to enable it to conduct the testing operations.
And then he extended that zinger with an excellent and relatable demonstration of using some of Spring4D’s facilities in working with anonymous functions, predicates, and LINQ-like data manipulation.
(I’m hoping we can gently encourage him into a full-length Spring4D presentation for ADUG sometime this year.)
Yes Sue. (Also last meeting). We went over 3 hours again ( oops ) … and we actually haven’t put out the last video yet, let alone this one … but releasing them as soon as we can is the goal post.
Maybe we can try to prioritise splitting out that section.
I had kinda sorta misplaced this photo from July 2023 when, with the direct help of @John_Walker, and the goodwill of everyone else, the Perth group started on the road to “Getting the Band Back Together” …
Great to see the video - and very useful to hear your perspective on things. It’s really useful for me - and in fact others in Embarcadero - to get some unvarnished feedback.
A couple of follow-ups (I haven’t watched the whole thing yet):
The “very unhappy guy on Facebook” was put in touch with me and several of us (including Marco) went through what he was saying, discussed it, and filled in a few gaps he had, and he passed on some of his code examples to us too.
When he had been emailing us he was using “resumes@” which is not a valid email address so it was falling into a pile of filtered mail. We do go through those, of course, I mean there could be one called “we_attack_at_dawn@” but it’s obviously not the most efficient route to getting our attention.
When I joined Embarcadero one of the things I really tried to do was make sure people like the guy you mentioned has a name, face, and a specific email address to get in touch. I do always respond, with a genuine response not a canned or AI generated reply. I do not want Embarcadero to seem to be a faceless monolithic corporation and I want users to understand that we actually do listen and we do act on genuine constructive feedback, good, bad, or otherwise.
This guy (I know his name but he uses a pseudonym so I will preserve his anonymity) is a case in point of why it’s important to be seen to be contactable and, more importantly, why a decent, honest, dialogue is the only way to solve things that can be solved and make sure the truth prevails whether it’s on Embarcadero’s side or not.
but it’s obviously not the most efficient route to getting our attention.