Wednesday, October 19, 2022

Digest for comp.lang.c++@googlegroups.com - 8 updates in 4 topics

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 19 01:53PM -0700

On 5/12/2022 12:16 PM, Chris M. Thomasson wrote:
> Using my experimental vector field to generate a fractal formation. Here
> is generation two:
 
> https://fractalforums.org/gallery/1612-120522191048.png
 
Fwiw, here is a result:
 
https://fractalforums.org/gallery/1612-191022205112.jpeg
 
from one of my older special Multi-Julia IFS algorithms. Here is the
base algo:
 
http://paulbourke.net/fractals/multijulia/
 
I still have the original code for this specific rendering, made back
over a decade ago, iirc. It was zoomed in. Kind of a bitch to do in an
IFS. Iirc, it had around a billion iterations, or over. I have to take a
look at my old code again...
 
Implementing all of this in C++ was well worth it.
Muttley@dastardlyhq.com: Oct 19 03:12PM

On Tue, 18 Oct 2022 17:40:05 +0100
>> Leverage is the outcome of using a lever, not a programming language.
 
>Yes leverage is the outcome of using a lever which is why it is a
>perfectly cromulent word to use when describing using a METAPHORICAL
 
Cromulent? Did you just flip a dictionary open at a random page or are you
just taking the piss?
 
>lever. It is NOT a buzzword.
 
Lever implies doing something you couldn't do before without it. It does not
apply in this case ergo you're just using it as a buzzword in order to try
and sound smart. Didn't work.
scott@slp53.sl.home (Scott Lurndal): Oct 19 03:35PM

>>perfectly cromulent word to use when describing using a METAPHORICAL
 
>Cromulent? Did you just flip a dictionary open at a random page or are you
>just taking the piss?
 
In this case, the use of "Cromulent" was perfectly cromulent :-)
 
The term originally was coined by a Simpsons writer, and has
subsequently reached the Merriam-Webster dictionary.
Manfred <noname@add.invalid>: Oct 19 02:43AM +0200

On 10/18/2022 10:06 AM, Jens wrote:
>   btn->OnClick = btnOnClick;  // <-- this fails
> ....
> }
 
I am not that familiar with Borland products, but from a C++ perspective
it would help if you could post the exact and complete error message -
this might show which are the types of the OnClick member, and of
btnOnClick.
 
You may also want to compare the following:
 
- declaration of the OnClick member of TButton - I guess this should be
documented by Borland - it may be an object of some class that overloads
the assignment operator; inspecting what is the expected argument type
of such operator might help
- prototype of btnOnClick
 
In C++ an "event" is not a built-in primitive. C++ offers all the lower
level ingredients to build an event system, so the details of events and
event handlers are specific to your implementation (Borland), and their
docs should tell how to use their events, rather than the language itself.
Jens <paule32.jk@gmail.com>: Oct 19 12:58PM +0200

Hello, and Thank You @all for ideas and feedback !
 
It seems, that the thing I would be done, does not
work without a class, and a class member.
 
I solved the problem, in this form:
 
//===
class MyDummyClass: public TObject
{
public:
void __fastcall SpeedButtonClick(System::TObject* Sender) {
ShowMessage("info speed.");
}
};
static MyDummyClass * dummyClass = NULL;
 
extern "C"
__declspec(dllexport) void
__stdcall create__MyCppFrame ( int ParentForm )
{
...
dummyClass = new MyDummyClass();
 
mySpeedButton = new TSpeedButton(myPanel);
mySpeedButton -> Parent = myPanel;
mySpeedButton -> OnClick = &(dummyClass->SpeedButtonClick);
...
}
//===
 
Thanks for your patient
Jens
Andrey Tarasevich <andreytarasevich@hotmail.com>: Oct 18 07:01PM -0700

On 10/18/2022 10:42 AM, Pawel Por wrote:
> {
> return 0;
> }
 
Your friend template it its current form has a non-template dependency
on the parameter `T` of the surrounding class template `BST`. Such
templates are legal in C++, but they can only be defined directly at the
point of declaration. C++ provides no syntax for defining them
out-of-class. If you define it right there, you should be fine
 
#include <iostream>
 
template<typename T>
struct BST
{
template<typename L>
struct BSTNode
{
int val = 42;
 
template<typename M>
friend std::ostream& operator<<(std::ostream& out,
const BSTNode<M>& elem)
{
out << elem.val;
return out;
}
};
};
 
int main(int argc, char **argv)
{
BST<int>::BSTNode<int> n;
std::cout << n;
}
 
However, this is still quite weird. Why did you decide to have
parameterized template dependency on the parameter `L` of `BSTNode`, but
no template dependency on the parameter `T` of `BST`? Either get rid of
both dependencies, i.e. turn your your operator into a non-template
 
#include <iostream>
 
template<typename T>
struct BST
{
template<typename L>
struct BSTNode
{
int val = 42;
 
friend std::ostream& operator<<(std::ostream& out,
const BSTNode& elem)
{
out << elem.val;
return out;
}
};
};
 
int main(int argc, char **argv)
{
BST<int>::BSTNode<int> n;
std::cout << n;
}
 
(note that in this variant you will still have to define the operator
in-class)
 
or keep both dependencies
 
#include <iostream>
 
template<typename T>
struct BST
{
template<typename L>
struct BSTNode
{
int val = 42;
 
template<typename U, typename V>
friend std::ostream&
operator<<(std::ostream& out,
const BST<U>::template BSTNode<V>& elem);
};
};
 
template<typename U, typename V>
std::ostream&
operator<<(std::ostream& out,
const typename BST<U>::template BSTNode<V>& elem)
{
out << elem.val;
return out;
}
 
int main(int argc, char **argv)
{
BST<int>::BSTNode<int> n;
operator<< <int>(std::cout, n);
}
 
In this variant it will become possible to define the friend function
outside the class. However, this version is problematic (read: useless)
since parameter `U` is in non-deduced context. The only way to call such
operator would be through a function calls syntax with explicit
specification of at least the first template argument, as shown in the
example above.
 
Basically, long story short, when it comes to templates prefer to define
friend functions right there in-class. That will save you from dealing
with some weird and unpleasant peculiarities of the language .
 
--
Best regards,
Andrey.
Andrey Tarasevich <andreytarasevich@hotmail.com>: Oct 18 07:14PM -0700

On 10/18/2022 11:22 AM, Bonita Montero wrote:
>>    out << elem.val;
>>    return out;
>> }
 
Nope.
 
Firstly, this should be
 
template<typename T, typename M>
std::ostream&
operator<<(std::ostream& out,
const typename BST<T>::template BSTNode<M>& elem)
{
...
 
Secondly, even if it makes the code "compilable", it still won't define
the same function as declared by the friend declaration. This is a
definition of a completely different template. The friend remains
undefined. Any attempts to invoke the friend operator will result in
"undefined reference" error.
 
--
Best regards,
Andrey
Bonita Montero <Bonita.Montero@gmail.com>: Oct 19 09:15AM +0200

Am 19.10.2022 um 04:14 schrieb Andrey Tarasevich:
> definition of a completely different template. The friend remains
> undefined. Any attempts to invoke the friend operator will result in
> "undefined reference" error.
 
He needs to define a different friend with the same signature.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)