Friday, August 24, 2018

Digest for comp.lang.c++@googlegroups.com - 25 updates in 5 topics

David Brown <david.brown@hesbynett.no>: Aug 24 09:29AM +0200

Recent discussions about constexpr got me thinking...
 
constexpr functions can be called with parameters that are compile-time
constants, in which case the result is also a compile-time constant, or
if they are called with run-time data they are run-time functions.
 
Is it possible to write a constexpr function that is equivalent to gcc's
__builtin_constant_p() feature? This is defined as:
 
_int __builtin_constant_p(exp)
 
returns 1 if "exp" is known to be a compile-time constant, and 0 if not
(optimisation flags may affect what the compiler knows and returns
here). The actual value of "exp" is not evaluated or used. The return
value of the builtin is itself always a compile-time constant.
 
 
Can you write something similar in C++, so that you have:
 
template<typename T> constexpr const bool isConstantExpression(T x);
 
 
I can't think of a way to do it myself, but maybe that's just my lack of
imagination.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Aug 24 10:03AM +0200

On 24.08.2018 09:29, David Brown wrote:
 
> template<typename T> constexpr const bool isConstantExpression(T x);
 
> I can't think of a way to do it myself, but maybe that's just my lack of
> imagination.
 
The following doesn't help, it outputs `false` with both g++ and Visual C++:
 
#include <iostream>
using namespace std;
 
auto main()
-> int
{
cout << boolalpha;
cout << noexcept( true? 0 : throw 0 ) << endl;
}
 
Cheers!,
 
- Alf
"Öö Tiib" <ootiib@hot.ee>: Aug 24 02:59PM -0700

On Friday, 24 August 2018 10:29:23 UTC+3, David Brown wrote:
 
> template<typename T> constexpr const bool isConstantExpression(T x);
 
> I can't think of a way to do it myself, but maybe that's just my lack of
> imagination.
 
That perhaps works:

#include <iostream>
#include <type_traits>
 
template<typename T>
constexpr typename std::remove_reference<T>::type makeprval(T && t)
{
return t;
}
 
int main(int argc, char *argv[])
{
int a = 1;
const int b = 2;
constexpr int c = 3;
const int d = argc;
 
// b and c are compile time constants but a and d are not.
std::cout << std::boolalpha;
std::cout << "a " << noexcept(makeprval(a)) << "\n";
std::cout << "b " << noexcept(makeprval(b)) << "\n";
std::cout << "c " << noexcept(makeprval(c)) << "\n";
std::cout << "d " << noexcept(makeprval(d)) << "\n";
}
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Aug 23 09:12PM +0200

[Sorry, I inadvertently first sent this follow-up as a reply mail.]
 
On 23.08.2018 20:27, Öö Tiib wrote:
>> people will sign the east const petition:
>> http://slashslash.info/eastconst
 
> Is it petition of programmers who sit facing North when programming? :)
 
 
No, because consistent left `const` requires a supporting syntax that
lets you consistently place `const` left.
 
You can get that as a library solution by defining
 
template<class T> using ptr_ = T*;
template<class T> using ref_ = T&;
 
But replacing `*` and `&` with such notation is too much for a formatter.
 
 
 
> Joining with that manifesto would benefit everybody better: https://utf8everywhere.org/
> Unfortunately it is also harder. Major doers like Windows, Qt, Java,
> C#, Python and ICU use some sort of UCS-2 or UTF-16 internally.
 
 
As I recall the manifesto is full of disinformation and unsubstantiated,
sometimes directly incorrect, claims. I.e. it's propaganda. It just
/looks/ technical.
 
In spite of the manifesto I think UTF-8 is the way to go now, after
Visual C++ got support, but the support in Windows, for both g++ and
Visual C++, is very incomplete.
 
In particular,
 
1 with both g++ and Visual C++ the `main` arguments are encoded as
Windows ANSI,
 
2 there's no reasonably direct way to get UTF-8 console i/o (though one
can use libraries like my header only ¹Wrapped stdlib), and
 
3 the standard library, e.g. `isspace`, is based on an assumption of
fixed length encoding.
 
Also, UTF-8 is /easy to get wrong and difficult to get right/ with
std::filesystem, which is designed with an assumption of Windows ANSI
narrow encoding in Windows. So we need a kind of UTF-8 oriented wrapper.
If anyone feels up to the task?
 
Cheers!,
 
- Alf
 
 
Links:
¹ https://github.com/alf-p-steinbach/Wrapped-stdlib
bitrex <user@example.net>: Aug 23 03:29PM -0400

On 08/23/2018 01:48 AM, Jorgen Grahn wrote:
> four places, but it seems I used it unnecessarily as a glorified
> const.
 
> /Jorgen
 
I've seen it used extensively in say a fixed-point math library as an
example, you have say some base class called say FixedPoint that defines
an interface and though your fundamental type is say a 32 bit integer
you might want an UnsignedFixedPoint<16,16> number with 16 integer bits
and 16 fractional, or SignedFixedPoint<18, 14>, or whatever.
 
"Under the hood" however everything is just represented by a word of
some bits, the processor doesn't care what it is. What it "is" is
defined entirely by its construction and particular way the operator
overloads are carried out, how much you shift when doing a multiply or w/e.
 
So you can just constexpr all that and if all goes well all the
appropriate operations for conversion and manipulation will be inlined
at compile-time, any immediate fixed-point type which is known at
compile-time will be generated appropriately, and there will be little
run-time overhead. The interface can probably even be CRTPed/static
polymorphism to avoid virtual call overhead, too.
bitrex <user@example.net>: Aug 23 03:34PM -0400

On 08/23/2018 03:29 PM, bitrex wrote:
> compile-time will be generated appropriately, and there will be little
> run-time overhead. The interface can probably even be CRTPed/static
> polymorphism to avoid virtual call overhead, too.
 
it's good to remember that you can constexpr lots of stuff, including
operator overloads and constructors. C++11 is a little restrictive in
what you can do there but anything after that you're more free
bitrex <user@example.net>: Aug 23 03:37PM -0400

On 08/23/2018 03:18 AM, Juha Nieminen wrote:
> than an external program. (Of course the drawback to this may be that
> the calculations would need to be done every single time that source
> code is recompiled, even if the calculated data itself remains the same.)
 
Post C++11 it's pretty dead-simple to generate entire lookup tables at
compile-time using templates and constexpr. It's a little more tricky
with C++11's tighter restrictions on constexpr but can still be done.
 
bitrex <user@example.net>: Aug 23 03:50PM -0400


> Brian
> Ebenezer Enterprises - Enjoying programming again.
> https://github.com/Ebenezer-group/onwards
 
Const pointers to mutable data make plenty of sense to me, but what do
when you want to write a move constructor for a class holding such a
pointer where the default-generated move constructor won't work for you.
You want to be able to assign the "other" class pointer to nullptr in
the move constructor body but can't, const-qualified pointers to mutable
data can only be modified in the initializer list.
 
Which is friggin' annoying because a const pointer to mustable data is
often just what you'd like to use in a move-only class, to enforce the
notion that this class is only reference-keeping for that member and not
actually copying data around. And unique ptr is not always appropriate
or even available.
legalize+jeeves@mail.xmission.com (Richard): Aug 23 09:16PM

[Please do not mail me a copy of your followup]
 
Jorgen Grahn <grahn+nntp@snipabacken.se> spake the secret code
 
>IME, if you're not sure about such a member, you have an unclear
>overall picture of the class, or you're unconciously in the process of
>redesigning it.
 
+1
 
Most of the places where I see difficulty with the use of const on
members is that the class design doesn't follow Command/Query
Separation design guideline.
<https://martinfowler.com/bliki/CommandQuerySeparation.html>
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Vir Campestris <vir.campestris@invalid.invalid>: Aug 23 11:13PM +0100

> It's nice to be able to agree with someone. Now I hope more
> people will sign the east const petition:
> http://slashslash.info/eastconst
 
Elsewhere we were talking about defects in the language. IMHO this is
one of them, along with the fact that
 
char* a,b;
 
declares two variables of different types.
 
I dare say back in the distant past this wasn't seen as a problem.
 
And constexpr? Like const, it should have been the default.
 
But it isn't, and we have to live with it.
 
Andy
Juha Nieminen <nospam@thanks.invalid>: Aug 24 08:18AM


>> the constness of a member function should indicate that it's thread-safe to
>> call it without a locking mechanism.
 
> But "f() const" doesn't indicate that at all. You can't make any assumptions about whether f mutates state.
 
I said "should", not "does". And it's not my idea. It's the idea of
people quite high up in the C++ design/standardization process.
 
Optimally, programs written in C++11 and prior should be designed so
that a const member function means it's thread-safe.
Reinhardt Behm <rbehm@hushmail.com>: Aug 24 04:39PM +0800

AT Friday 24 August 2018 16:18, Juha Nieminen wrote:
 
> people quite high up in the C++ design/standardization process.
 
> Optimally, programs written in C++11 and prior should be designed so
> that a const member function means it's thread-safe.
 
A const member function only promises that it itself will not to change the
object. That does not mean it will not be changed from another thread.
So the promise is not that it does not change because the function has no
control of this.
 
--
Reinhardt
Paavo Helde <myfirstname@osa.pri.ee>: Aug 24 03:03PM +0300

On 24.08.2018 11:39, Reinhardt Behm wrote:
>> that a const member function means it's thread-safe.
 
> A const member function only promises that it itself will not to change the
> object.
 
No, it does not promise that. In particular, the 'mutable' keyword
exists precisely for allowing const member functions to change data.
 
What Juha is talking about (I think) is that if a const member function
changes anything then it should do this under an appropriate internal
mutex lock or equivalent.
 
> That does not mean it will not be changed from another thread.
> So the promise is not that it does not change because the function has no
> control of this.
 
Sure, in this approach one needs to apply an external lock in all
threads if one wants to call any non-const member function in some thread.
 
This is how STL containers like std::string and std::vector work, for
example.
Richard Damon <Richard@Damon-Family.org>: Aug 24 08:53AM -0400

On 8/21/18 11:58 AM, Juha Nieminen wrote:
> there can only be performance benefits from it, never drawbacks.
> (Even if the constexprness never realizes itself at compile time,
> you haven't lost anything in terms of performance.)
 
My one thought is that with this sort of rule it will lead to lasy
thinking. When you create a function/variable, you should KNOW if it is
supposed to be constant or variable. If it should be constant, make it
const/constexpr. If not (but perhaps for now might be) don't. That way
you catch both types of errors, changing something that should be const,
or depending on something to be const that isn't really. Getting in the
habit of just removing the const because it causes an error says that
you may miss some mistakes of changing something that should have been
const because the error is no longer an 'error' in your mind, just a
flag to make a change. Marking thing const that shouldn't be (and this
is more apt to be a problem with functions than variables) means you may
use something as const when it shouldn't be, and then later when you
want to make it non-const, you find that you can't as that makes other
errors where it was assumed to be const.
 
At the interface, const/non-const is an active part of the interface and
needs to be carefully thought of, as a change IS an interface change.
 
Internals may be less important, with less far reaching issues, but
still really should be though of ahead of time, and changes be
deliberate, and not just to silence errors/warnings.
 
constexpr works the same way. Marking something constexpr that isn't
fundamentally so, but just happens to be, allows it to be used in ways
that it shouldn't be, and constrains future modifications that might
have been intended.
Daniel <danielaparker@gmail.com>: Aug 24 06:03AM -0700

On Friday, August 24, 2018 at 4:39:26 AM UTC-4, Reinhardt Behm wrote:
 
> A const member function only promises that it itself will not to change the
> object.
 
But const happily allows
 
struct A
{
int* p;
 
A()
{
p = new int[2];
}
 
void f() const
{
p[0] = 1;
}
};
 
int main()
{
A a;
a.f();
}
 
Daniel
boltar@cylonHQ.com: Aug 24 01:56PM

On Fri, 24 Aug 2018 06:03:02 -0700 (PDT)
 
>> A const member function only promises that it itself will not to change the
>> object.
 
>But const happily allows
 
Which is why I rarely both with this syntactic sugar - too many exceptions.
Far better to make sure any future programmers read the code rather than just
assuming IMO.
bitrex <user@example.net>: Aug 24 10:21AM -0400

On 08/24/2018 08:53 AM, Richard Damon wrote:
> fundamentally so, but just happens to be, allows it to be used in ways
> that it shouldn't be, and constrains future modifications that might
> have been intended.
 
I agree, for example if there were only benefits and no drawbacks why
not just make "constexpr" the default behavior for everything in the
standard and make the programmer un-constexpr what they didn't want to
have that behavior with some keyword like marking functions "mutable"
or something.
 
Don't see any reason intrinsically it couldn't be that way other than
there are better reasons to have it the way it is than that way.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 24 04:00PM +0100

On 24/08/2018 14:03, Daniel wrote:
> A a;
> a.f();
> }
 
Of course it should happily allow that and I see no problem with that.
 
/Flibble
 
--
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That's what I would say."
Reinhardt Behm <rbehm@hushmail.com>: Aug 25 12:06AM +0800

AT Friday 24 August 2018 21:03, Daniel wrote:
 
> a.f();
> }
 
> Daniel
 
p[0] is not part of A, only p, and that is not changed.
 
--
Reinhardt
Daniel <danielaparker@gmail.com>: Aug 24 11:28AM -0700

On Friday, August 24, 2018 at 12:06:54 PM UTC-4, Reinhardt Behm wrote:
> > a.f();
> > }
 
> p[0] is not part of A, only p, and that is not changed.
 
p[0] is state that is owned by the instance a, and allowing that state to be mutated precludes reasoning about f() const in the same way as reasoning about a pure function. In particular, the ability to draw conclusions about thread safety goes out the window.
 
f() const has a well defined meaning, but that meaning does not correspond to that of a pure function, and it's unclear what the benefits are compared to pure. Its meaning seems to me to be mostly formal.
 
Daniel
Daniel <danielaparker@gmail.com>: Aug 24 12:21PM -0700

On Friday, August 24, 2018 at 11:00:38 AM UTC-4, Mr Flibble wrote:
 
> Of course it should happily allow that and I see no problem with that.
 
The issue is that by looking at a function signature, say,
 
size_t size() const;
 
neither you (nor the compiler) can conclude anything about whether size() const is or is not mutating. Whether the data member is stored in size_t size_ or in size_t* size_ is an implementation detail that is neither here nor there. This greatly reduces the value of the const qualifier, to the point where it's merely suggestive, nothing more.
 
Daniel
Lynn McGuire <lynnmcguire5@gmail.com>: Aug 23 08:14PM -0500

"Modern C++" != "New(est) Standard"
https://arne-mertz.de/2018/08/modern-c-newest-standard/
 
After writing code in Smalltalk for several years, I love strong typing.
 
Lynn
"Öö Tiib" <ootiib@hot.ee>: Aug 23 11:30PM -0700

On Friday, 24 August 2018 04:14:20 UTC+3, Lynn McGuire wrote:
> "Modern C++" != "New(est) Standard"
> https://arne-mertz.de/2018/08/modern-c-newest-standard/
 
> After writing code in Smalltalk for several years, I love strong typing.
 
He forgets to mention loose, minimally intrusive coupling.
Thanks to lambdas we do not need type unsafe void(*)(void*)
and void* pair for that.
 
Most modern from C++17 are variant and optional. Simply awesome
and ridiculously useful. The union was always unsafe and usage of
raw or unique_ptr to represent little, possibly missing value was
so sadly inefficient.
Sky89 <Sky89@sky68.com>: Aug 23 06:48PM -0400

Hello....
 
My next software projects..
 
As you have noticed i have implemented graphical Winmenus, it is an
interesting Widget that i have designed myself, i will enhance it more,
but as also you have noticed that the zipfile of my Winmenus using
Wingraph contains my 64 bit windows executabe demo called real3d1.exe
that makes you take a look at my Winmenus widget and it contains a 3D
Opengl demo and other demos , please execute this real3d1.exe to look at
how powerful is my graphical program, i have also made Wingraph
compatible with FreePascal and Delphi including Delphi tokyo, so that
you will be able to prototype rapidly 3D "Opengl" graphical programs,
you can download my graphical Winmenus using wingraph from:
 
https://sites.google.com/site/scalable68/winmenus-using-wingraph
 
 
And as i will enhance soon my graphical Winmenus
Here is my next software projects that i will implement and "invent":
 
Here is my other software project for Delphi and FreePascal that i will
finish soon:
 
1- I will support async and await
 
2- I will support futures
 
3- I will support "scalable" Parallel Foreach with priorities that will
be very "powerful" using my "scalable" Threadpools with and without
priorities.
 
Here is my Threadpool with priorities that i have invented and that
scales very well (i have invented another "fully" scalable Threadpool
that is really powerful), read about it and download it from here:
 
https://sites.google.com/site/scalable68/an-efficient-threadpool-engine-with-priorities-that-scales-very-well
 
And here is my last project in FreePascal and Delphi(including Delphi
tokyo) that i have "invented", it is a "scalable" reference counting
with efficient support for weak references, you will not find it in C++
and you will not find it in Rust, read about it and download it from here:
 
https://sites.google.com/site/scalable68/scalable-reference-counting-with-efficient-support-for-weak-references
 
 
I have also "invented" my C++ synchronization objects library,
read about it and download it from here:
 
https://sites.google.com/site/scalable68/c-synchronization-objects-library
 
You have to understand my work..
 
I have invented many scalable algorithms and there implementations, here
is some of them that i have "invented":
 
1- Scalable Threadpools that are powerful
 
2- Scalable RWLocks of different sorts.
 
3- Scalable reference counting with efficient support for weak references
 
4- Scalable FIFO queues that are node-based and array-based.
 
5- My Scalable Varfiler
 
6- Scalable Parallel implementation of Conjugate Gradient Dense Linear
System Solver library that is NUMA-aware and cache-aware, and also a
Scalable Parallel implementation of Conjugate Gradient Sparse Linear
System Solver library that is cache-aware.
 
7- Scalable MLock that is a scalable Lock.
 
8- Scalable SeqlockX
 
 
And there is also "many" other scalable algorithms that i have "invented".
 
You can find some of my scalable algorithms and there implementations in
Delphi and FreePascal and C++ on my website here:
 
https://sites.google.com/site/scalable68/
 
What i am doing by "inventing" many scalable algorithms and there
implementations, is wanting to make "Delphi" much better and making
FreePascal on the "Delphi" mode much better, my scalable algorithms
and there implementations are like HPC(high performance computing,
and as you have noticed i said also:
 
You will ask why have i invented many scalable algorithms and
there implementations? because also my work will permit us also to
"revolutionise" science and technology because it is HPC(high
performance computing), this is why i will also sell some of my scalable
algorithms and there implementations to companies such as Google or
Microsoft or Embarcadero.
 
Also HPC has revolutionised the way science is performed. Supercomputing
is needed for processing sophisticated computational models able to
simulate the cellular structure and functionalities of the brain. This
should enable us to better understand how our brain works and how we can
cope with diseases such as those linked to ageing and to understand more
about HPC, read more here:
 
https://ec.europa.eu/digital-single-market/en/blog/why-do-supercomputers-matter-your-everyday-life
 
And i think i will "sell" "some" of my scalable algorithms and there
implementations to Google or to Microsoft or to Embarcadero.
 
I will also enhance my Parallel archiver and my Parallel compression
Library that are powerful and that work with both C++Builder and Delphi
and to perhaps sell them to Embarcadero that sells Delphi and C++Builder.
 
About portability of my software projects
 
I have thought more, and as you have noticed i have written Intel
assembler routines for 32 bit and 64 bit for atomically incrementing and
and for atomically CompareExchange etc. so now they are working with x86
AMD and Intel processors for 32 bit and 64 bit, but i will soon make my
Delphi and FreePascal and C++ libraries portable to the other CPUs like
ARM(for Android) etc. for that i will use the following Delphi methods
for Delphi:
 
http://docwiki.embarcadero.com/Libraries/XE8/en/System.SyncObjs.TInterlocked.CompareExchange
 
and
 
http://docwiki.embarcadero.com/Libraries/Tokyo/en/System.SyncObjs.TInterlocked.Exchange
 
 
And I will use the same functions that you find inside FreePascal, here
they are:
 
https://www.freepascal.org/docs-html/rtl/system/interlockedexchange64.html
 
and
https://www.freepascal.org/docs-html/rtl/system/interlockedexchange.html
 
and
 
https://www.freepascal.org/docs-html/rtl/system/interlockedcompareexchange.html
 
and
 
https://www.freepascal.org/docs-html/rtl/system/interlockedcompareexchange64.html
 
 
I will use them inside my scalable lock that is called scalable MLock
that i have "invented", so that it will be portable, here it is:
 
https://sites.google.com/site/scalable68/scalable-mlock
 
 
And when my scalable MLock will become portable on Delphi and FreePascal
i will port with it all my other libraries that uses atomically
increment and decrement etc., so my libraries will become portable to
the other CPUs like ARM for Android etc., so i think you will be happy
with my work.
 
About Extreme Scaling in CAE Applications..
 
I have just read the following about Ansys company:
 
https://en.wikipedia.org/wiki/Ansys
 
 
Notice that Ansys develops and markets finite element analysis software
used to simulate engineering problems.
 
I think that i have thought about this, and i have "invented"
a Scalable Parallel C++ Conjugate Gradient Linear System Solver Library,
in fact it scales "very" well, my library contains a Scalable Parallel
implementation of Conjugate Gradient Dense Linear System Solver library
that is NUMA-aware and cache-aware, and it contains also a Scalable
Parallel implementation of Conjugate Gradient Sparse Linear
System Solver library that is cache-aware.
 
Sparse linear system solvers are ubiquitous in high performance
computing (HPC) and often are the most computational intensive parts in
scientific computing codes. A few of the many applications relying on
sparse linear solvers include fusion energy simulation, space weather
simulation, climate modeling, and environmental modeling, and finite
element method, and large-scale reservoir simulations to enhance oil
recovery by the oil and gas industry.
 
Conjugate Gradient is known to converge to the exact solution in n steps
for a matrix of size n, and was historically first seen as a direct
method because of this. However, after a while people figured out that
it works really well if you just stop the iteration much earlier - often
you will get a very good approximation after much fewer than n steps. In
fact, we can analyze how fast Conjugate gradient converges. The end
result is that Conjugate gradient is used as an iterative method for
large linear systems today.
 
You can download my Scalable Parallel C++ Conjugate Gradient Linear
System Solver Library from here:
 
https://sites.google.com/site/scalable68/scalable-parallel-c-conjugate-gradient-linear-system-solver-library
 
Read the following about Extreme Scaling in CAE Applications, this is
why i have invented my Scalable Parallel C++ Conjugate Gradient Linear
System Solver Library that scales very well:
 
https://www.cray.com/blog/extreme-scaling-in-cae-applications/
 
 
You can find some of my other software projects here:
 
https://sites.google.com/site/scalable68/
 
 
 
Thank you,
Amine Moulay Ramdane.
Sky89 <Sky89@sky68.com>: Aug 23 04:43PM -0400

Hello...
 
Read this:
 
 
My Winmenus using wingraph was updated to version 1.02
 
Now it is both compatible with Delphi and with FreePascal, now
it works with Delphi tokyo, but there is only one difference between
Delphi and FreePascal, the double click with the left button of the
mouse of freepascal is replaced in Delphi with a one click with the
middle button of the mouse to avoid a problem.
 
You can now download both the zipfiles for FreePascal and for Delphi.
 
You can download my Winmenus using wingraph from:
 
https://sites.google.com/site/scalable68/winmenus-using-wingraph
 
 
I have implemented Winmenus using wingraph, this one is graphical, i
have also included an Opengl demo and other demos , just execute the
real3d1.exe executable inside the zipfile to see how it is powerful, i
will soon enhance much more my Winmenus.
 
WinMenus using wingraph version 1.02
 
Author: Amine Moulay Ramdane
 
Description:
 
Drop-Down Menu widget using the Object Pascal wingraph unit , it
supports keyboard and mouse. Please look at the real3d1.pas demo inside
the zip file, i have included its 64 bit executable, please run it and
see(please double click with the mouse on the items to execute and click
on the middle mouse to stop the demo, and press escape to exit from the
demo).
 
And use the 'Up' and 'Down' and 'PageUp and 'PageDown' to scroll the menu..
And 'Enter' to select an item from the menu..
And the 'Esc' on the keyboard to exit from the menu..
 
and right arrow and left arrow to scroll on the left or on the right of
the menu
 
Winmenus is event driven, i have to explain it more to you to understand
more...
 
At first you have to create your Widget menu by executing something like
this:
 
Menu1:=TMenu.create(5,5);
 
This will create a Widget menu at the coordinate (x,y) in characters =
(5,5)
 
After that you have to set your callback function, cause my Winmenus is
event driven, so you have to add an item with AddItem() and set the
callback function at the same time, like this:
 
AddItem('First 3D opengl demo',test1);
 
test1 will be the callback function.
 
When you execute menu1.execute(false) with a parameter equal to false my
Winmenus widget will draw your menu without waiting for your input and
events, when you set the parameter of the execute() method to true it
will wait for your input and events, if the parameter of the execute
method is true and the returned value of the execute method ctExit that
means you have pressed on the Escape key to exit.
 
Language: FPC Pascal v2.2.0+ / Delphi 7+: http://www.freepascal.org/
 
Operating Systems: Windows..
 
Required FPC switches: -O3 -Sd
 
-Sd for delphi mode....
 
 
 
Thank you,
Amine Moulay Ramdane.
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)