Saturday, September 29, 2018

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

superduperhengyuan@gmail.com: Sep 28 08:10PM -0700

CookMem is a a memory context / allocator written in C++11 that can be easily and quickly cleaned up by freeing the segments, rather than doing individual frees. It is extremely useful to deal with third party libraries that can potentially have memory leaks, or to simplify the memory management.
 
The secondary goal of this project is to provide a good enough performance that should be comparable to dlmalloc and its derivatives. In fact, the algorithms and some code used here are mostly based on dlmalloc. I basically took the pain to understand dlmalloc and rewrote the logics in C++. Some key calculations though are kept the same as dlmalloc since there is no point to reinvent wheels.
 
Github page: https://github.com/coconut2015/cookmem
Project documentation: https://coconut2015.github.io/cookmem/index.html
 
It is licensed under APL 2.0.
Paavo Helde <myfirstname@osa.pri.ee>: Sep 29 10:19AM +0300

> CookMem is a a memory context / allocator written in C++11 that can be easily and quickly cleaned up by freeing the segments, rather than doing individual frees. It is extremely useful to deal with third party libraries that can potentially have memory leaks, or to simplify the memory management.
 
Just for curiosity: how do you convince a crappy third-party library to
use this allocator? And how do you know when it's safe to release the
memory?
 
From the first glance it seems it is lacking the standard
std::allocator interface and std::allocator_traits, which makes it
harder to use with non-crappy third-party C++ libraries.
 
Also, how does this compare with other existing pool allocators like the
Boost Pool Library?
superduperhengyuan@gmail.com: Sep 29 12:49AM -0700

On Saturday, September 29, 2018 at 12:19:52 AM UTC-7, Paavo Helde wrote:
 
> Just for curiosity: how do you convince a crappy third-party library to
> use this allocator? And how do you know when it's safe to release the
> memory?
 
The safest approach is to replace malloc / free. It does not matter if the third party library is C or C++. Before calling the third party library, switch malloc / free to use a memory pool. Once the call is finished, destroy the memory pool and switch back to whatever the previous memory pool or malloc / free.
 
You can take a look at how I do the performance test to compare dlmalloc vs CookMem:
 
https://github.com/coconut2015/cookmem/blob/master/performances/
 
 
> From the first glance it seems it is lacking the standard
> std::allocator interface and std::allocator_traits, which makes it
> harder to use with non-crappy third-party C++ libraries.
 
I believe the allocator interface just need a allocate() and deallocate(). So you use cookmem::MemPool as allocator.
 
That said, it is better to just replace malloc / free / new / delete since it is very error prone mixing allocators (or at least my perception is that it is error prone).
 
 
> Also, how does this compare with other existing pool allocators like the
> Boost Pool Library?
 
Before I started working on CookMem, I did look around for similar stuff and nothing like it is available in C++ as open source. Boost Pool is for fixed size allocations. That is why it is quite simple to implement and very limited in functionality.
 
Heng Yuan
"Öö Tiib" <ootiib@hot.ee>: Sep 29 05:41AM -0700


> Github page: https://github.com/coconut2015/cookmem
> Project documentation: https://coconut2015.github.io/cookmem/index.html
 
> It is licensed under APL 2.0.
 
Is my impression correct that it is only useful for single-threaded
software? That might be crippling in world where even phones are
quad core.
Paavo Helde <myfirstname@osa.pri.ee>: Sep 29 08:33PM +0300

>> use this allocator? And how do you know when it's safe to release the
>> memory?
 
> The safest approach is to replace malloc / free. It does not matter if the third party library is C or C++. Before calling the third party library, switch malloc / free to use a memory pool. Once the call is finished, destroy the memory pool and switch back to whatever the previous memory pool or malloc / free.
 
This sounds like enforcing a strictly single-threaded program, is this so?
 
Also, how exactly do you redirect malloc/free dynamically? It's already
pretty tricky enough to do it statically for the whole program,
especially in Windows.
 
This also assumes that the third-party library does not maintain any
internal state which uses dynamic memory, otherwise it might crash badly
in the next call or upon program exit. Not to speak about that a
third-party library may even decide to spawn its own background threads
which might not like if global malloc/free were changed under their feet.
 
>> harder to use with non-crappy third-party C++ libraries.
 
> I believe the allocator interface just need a allocate() and deallocate(). So you use cookmem::MemPool as allocator.
 
> That said, it is better to just replace malloc / free / new / delete since it is very error prone mixing allocators (or at least my perception is that it is error prone).
 
Yet you are proposing mixing allocators *on the fly*! If that's not
error-prone I do not know what is. Imagine having a local std::string
variable in a function which changes the global malloc/free.
 
 
>> Also, how does this compare with other existing pool allocators like the
>> Boost Pool Library?
 
> Before I started working on CookMem, I did look around for similar stuff and nothing like it is available in C++ as open source. Boost Pool is for fixed size allocations. That is why it is quite simple to implement and very limited in functionality.
 
I have implemented a special pooled allocator for parsing and loading
large XML files into memory. This would be a use case for a
variable-size pooled allocator, but definitely this allocator would be
used only for a certain data structure and should not replace the global
malloc. For example, if I throw an exception during the XML parse I do
not want the error message string to be allocated in the pooled allocator!
superduperhengyuan@gmail.com: Sep 29 10:53AM -0700

On Saturday, September 29, 2018 at 5:41:18 AM UTC-7, Öö Tiib wrote:
 
> Is my impression correct that it is only useful for single-threaded
> software? That might be crippling in world where even phones are
> quad core.
 
Hi, currently I did not add locking code. This can be easily added later but not a focus.
 
The intention is that each thread should have its memory pool through thread local or whatever other means.
 
One use case is that if one thread is about to exit, suspended. We want to release all the memory associated with that thread. Can we release all the resources associated with that thread. Using this memory pool can do so.
 
Obviously, there are other pieces you need to incorporate this memory pool.
 
Heng Yuan
superduperhengyuan@gmail.com: Sep 29 11:22AM -0700

To Paavo Helde,
 
I answered the question of single thread in another post. Please refer to that. Although I do forgot to add if the 3rd party library is multithreaded, you obviously would want to avoid using CookMem for now. Most of the time though, the reason we would want to use 3rd party code is because of some utility thing that is usually single threaded.
 
Regarding mixing allocators. There will be complicated cases where you have one allocator that should be freed, and another allocator that is still in use. Here is an example that deals with this situation:
 
https://github.com/coconut2015/cookmem/blob/master/examples/ex_4.cpp
 
Obviously, it is not trivial. At least memory pool provides a tool for you to extract specific stuff out of it before discarding the rest.
 
Now as for shared memory / context by third party libraries. Obviously you will need to be extremely careful. There are initiation related memory, execution related, and the scope of the memory pool needs to be carefully considered. At work, I have encountered situations like this that must be carefully dealt with, but it is definitely doable.
 
Overall, the use of memory pool is not going to be trivial. You need a lot of other pieces (architectural design etc) to even begin using it. Also, it is not supposed to be an end-all-solve-all solution. It is just one solution. That said, sometimes it can be the best solution.
 
Heng Yuan
Marcel Mueller <news.5.maazl@spamgourmet.org>: Sep 29 09:57PM +0200

> The safest approach is to replace malloc / free. It does not matter if the third party library is C or C++. Before calling the third party library, switch malloc / free to use a memory pool. Once the call is finished, destroy the memory pool and switch back to whatever the previous memory pool or malloc / free.
 
This will sadly fail for many libraries as they tend to use internal
caching. I.e. allocate some objects statically when they are needed
first. These objects are used for later library calls.
 
So unless your library is explicitly stated to use /no persistent data
objects/ the resulting program will always have undefined behavior. And
I never have seen a library that guarantees to make no non-temporary
allocations - except for those which do not use dynamic memory at all,
of course.
 
 
Marcel
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Sep 29 11:01AM -0400

On 9/28/2018 6:00 PM, Rick C. Hodgin wrote:
> Satan is only an imitator, Leigh. He's not an originator.
> God had many names, so he imitated God when he invented
> Islam to deceive people into following a false religion.
 
 
The Bible records only three times where the actual voice
of Satan is recorded: (1) when Satan tempted Adam and Eve,
(2) in the book of Job where God talks to Satan, and (3)
when Jesus was being tempted.
 
In those verses Satan revealed his plan for how to deceive
mankind. His m.o. has never changed:
 
(1) "God's not being good enough to you."
(2) "God, you're being too good..."
(3) "If you'll worship me, I'll be better to you
than God is."
 
In (1) Satan said to Adam and Eve "Hath God said you shall
not eat of the fruits of the garden? ... You will not surely
die, for God knows on the day you eat of it you will be like
God, knowing good and evil." Translation: God's holding
out on you. He's withholding His blessing. You need to lis-
ten to me and I'll teach you the true path to enlightenment.
 
In (2) God addresses Satan in Heaven, and Satan responds:
"Does Job worship you for nothing? You have put a hedge
around Him and blessed the work of his hands." Translation:
God, you're too good to Job. If you take away the many
blessings you've given him, he will curse you to your face.
And for act 2, God again addresses Satan and this time when
Satan responds he says, "Skin for skin. A man will give
all he has to save his skin," so God allows Satan to in-
flict his body with great sickness, but he could not take
his life. Satan covers Job's body with hideous and pain-
ful boils from the soles of his feet to the crown of his
head. But in all of this, when all his possessions were
taken away, and when his health was completely miserable,
never did Job curse God, nor reject Him.
 
In (3) Satan comes to tempt Jesus in the wilderness. He
says, "You see all this? It has been given to me, and I
can give it to whomever I choose. If you will bow down
and worship me, I will give you all these kingdoms."
Translation: God would never give you all this. If you
want to have true riches, you must come to me, for I am
willing to bless you beyond that which God will.
 
In each of these cases you see Satan pitting man against
God, God against man, and then Satan steps in to be the
good guy.
 
In Islam, it's the same m.o. Islam charges that Christianity
had become corrupted, and Allah had to step in to undo the
multitude of corruptions, correcting what the false Christian
church had done in error for centuries.
 
Islam introduces division between the Jewish and Christian
God and man, and between man and their faith, and then swoops
in to be the solution, just like in the 1..2..3 example he's
always used.
 
-----
Jesus denied Satan's offer, and we read in Matthew 28:18
that after Jesus completed the work of God at the cross,
and was raised on the third day, all power and authority
in Heaven and on the Earth (not just the kingdoms of the
Earth Satan was offering) have been given to Jesus.
 
For each of us, but turning away from Satan and following
only after God the Father, His Son Jesus Christ, and the
Holy Spirit, so are we doing rightly here in this world,
and we will receive the full reward after we leave this
world.
 
It comes down to the gift of faith given by God to all
who are being saved. You will know if God is calling you
to be saved on the inside of your heart. He presents Him-
self in a way that you can uniquely identify and know that
it is His call, and not some deception. You will also
read these words and here a confirmation in your spirit,
which is being awakened by God as He alone is the giver of
life, both of physical life, and of spiritual life, and
that new understanding you discern coming into your life,
the way you are realizing that you're looking at things
differently than you use to, it's all evidence of the work
of God in your spirit in your life, which will culminate
in you coming to Jesus in repentance, asking forgiveness
for your sin, and receiving eternal life, and being forever
changed here in this world to start, and then on into
eternity.
 
Consider the songs taught by the enemy of God through
sinful men and women. Pick the top 10 songs of any year
and go through the lyrics and compare them to the teach-
ings of the Bible, and of the guidance by the Holy Spirit.
 
You'll find that of those top 10 they are either teaching
directly against God's teachings, or are fairly neutral
and serve as gateway songs to get you to buy the album so
you can then hear the teachings later which are false in
the rest of the songs.
 
Very rarely in anything mainstream will see Christ pre-
sented properly. Even in TV shows like When Calls The
Heart on Hallmark Channel, which has an early 1900s set-
ting, and a relatively strong Christian presence in the
community, still when they quote Bible verses they do
not quote them accurately. They'll say "Corinthians"
when they cite something, rather than "1st Corinthians"
or "2nd Corinthians." They use the term "good book"
rather than the Bible, etc.
 
The true God of the universe, God the Father, God the
Son, God the Holy Spirit, is being suppressed in this
world by the enemy, who wants to keep us following after
him, after sin, after wrong things, so he can keep us
trapped on that road to Hell, in unrepentance, under
condemnation, in judgment, etc.
 
I urge you to investigate these things and see for
yourself. Go to the pages of scripture and read for
yourself the teachings of the Holy Spirit, and see if
they align with the things of this world, explaining
it exactly, and see if you can't also see that division
which exists between the people who follow after God in
this world, and the enemy who seeks to have us following
after him in God's place.
 
--
Rick C. Hodgin
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Sep 29 04:58PM +0100

On 29/09/2018 16:01, Rick C. Hodgin wrote:
> On 9/28/2018 6:00 PM, Rick C. Hodgin wrote:
[snip] (tl;dr)
 
Fucktard who thinks that Satan invented fossils, fuck off.
 
/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."
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Sep 29 10:39AM -0700

On Saturday, September 29, 2018 at 11:59:05 AM UTC-4, Mr Flibble wrote:
> On 29/09/2018 16:01, Rick C. Hodgin wrote:
> > On 9/28/2018 6:00 PM, Rick C. Hodgin wrote:
> [snip] (tl;dr)
 
Was posted for those who can hear the truth, and are being saved.
 
> .. who thinks that Satan invented fossils, .. .
 
Never said that. Don't believe it. Fossils exist. They are not
millions/billions of years old. That's the lie.
 
--
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Sep 29 01:21PM -0400

Totally off-topic post, but if you like technology (hardware and/
or software) you may find it interesting. It's on Netflix, and a
TV station in Canada (where it was produced).
 
==> Spoilers! Just read the top part before the episode listing:
https://en.wikipedia.org/wiki/ReBoot:_The_Guardian_Code
 
I have found this new TV show interesting. It's a Netflix original
about four high school students drafted into service inside cyber-
space. They enter a special room with something like a transporter
pad from Star Trek, but instead of beaming someplace else, they beam
into cyberspace as code (the "Guardian Code"). There, they are
drafted into service and fight viruses and enemies.
 
If you remember the TV show ReBoot from the 1990s, this is a reboot
of that show. It has a notably different flavor. MegaByte is back
with an upgrade. We get to see Dot and Enzo, Bob and Hexadecimal,
all in MainFrame, which is one part of cyberspace the Guardians go
to.
 
-----
It's one of the best Sci-Fi shows I've ever seen.
 
Netflix released episodes 1-10 earlier this year as season 1, and
have just released episodes 11-20 as season 2. In Canada, the whole
series has been available for a few months.
 
This apparently will be the end of the series as I do not believe
it's been picked up for another season, but, it is such a well-writ-
ten show. The concepts are creative and the 3D scenes in cyberspace
are all done using the UNREAL gaming engine. When cyber-locusts at-
tack, they're using the gaming engine's AI to coordinate their fly-
ing so they don't collide with one another, nor the scene. It al-
lowed them to have such high volumes of animated characters, accord-
ing to an interview I saw on YouTube earlier this year.
 
The show begins by laying down some basic concepts, and some of the
acting is weak in the first few episodes in my opinion, but it picks
up mid-first season, and the story line is very compelling. The
actress who plays V.E.R.A, and the actor who plays Sourcerer (the
main bad guy) ... they deserve awards for their roles.
 
I'm on episode 6 of season 2. Episodes 11+ really amp up the show.
I would like to see a season 3 pickup.
 
If you like Sci-Fi, I think you might really like this show. I'd
be curious to hear some reviews about it. Please email me privately
if you prefer.
 
Thank you.
 
--
Rick C. Hodgin
David Brown <david.brown@hesbynett.no>: Sep 29 01:44PM +0200

On 28/09/18 22:23, Öö Tiib wrote:
> iOS device than formula (1). I surely checked that it was also
> better in particular case (lot of verifying if points were in
> ranges or not) on Mac.
 
The two formula are close to equivalent, but not entirely. They
certainly rely on the condition that a <= c, and may be different in
cases near wrappings (I haven't thought about it enough to tell).
 
I would want compilers to make such transformations when it makes a
difference and it is known to be correct - I don't want to have to start
messing with these myself. I have certainly seen gcc make such
transformations.
 
I also expect compilers to make the right choice between code with
conditional jumps and alternatives such as conditional moves. In some
cases, branches are cheaper (even on modern OOO cpus) - in other cases,
they are more expensive. What is almost certainly true is that the
compiler writers know more about it than the average C++ programmer.
 
 
So write your source code in the clearest and most logical manner. Then
if you are convinced the compiler is generating sub-optimal code, file a
"missed optimisation" bug for it.
"Öö Tiib" <ootiib@hot.ee>: Sep 29 07:14AM -0700

On Saturday, 29 September 2018 14:44:18 UTC+3, David Brown wrote:
 
> The two formula are close to equivalent, but not entirely. They
> certainly rely on the condition that a <= c, and may be different in
> cases near wrappings (I haven't thought about it enough to tell).
 
Exactly! The formulas can give different results when the length
overflows (undefined behavior) or when it is negative. On case
of ranges such situations are programming errors and should be
dealt with where the ranges are formed, but with just any a, b, c
these are perfectly legal situations.
 
> cases, branches are cheaper (even on modern OOO cpus) - in other cases,
> they are more expensive. What is almost certainly true is that the
> compiler writers know more about it than the average C++ programmer.
 
C++ compiler does not understand concept of ranges. At least not
before "Concept" of "Range" is added to it. ;) It is up to its
implementers to make std::vector as 3 pointers or pointer and 2
lengths but it can't decide if we store representation of our
"ranges" as start and end pair or as start and length pair.
 
Latter was optimal on described case, but it may be sub-optimal
on some other.
 
Now if we choose start and length then it still does not understand
what these are and so it can not convert 'a < b && b < a + len'
into '(unsigned)(b - a) < len' because negative 'len' may make
sense in some other context and then the formulas are different.
 
 
> So write your source code in the clearest and most logical manner. Then
> if you are convinced the compiler is generating sub-optimal code, file a
> "missed optimisation" bug for it.
 
I generally write code in most simple and logical manner because it is
only about 5% of it that can possibly alter perceivable performance.
The attempt here was to post something thought-provoking
as alternative to stuff from ramine, leigh and rick that does
not matter any to me.
Richard Damon <Richard@Damon-Family.org>: Sep 29 01:09PM -0400

On 9/27/18 4:41 PM, Vir Campestris wrote:
 
> APL is burned into my brain. I'm scarred by it - traumatised even.
 
> It was strict right to left evaluation. No precedence.
 
> Andy
 
I presume APL didn't try to define an operator precedence because it has
SO many operators no one could agree on an order, let alone attempt to
remember it.
Ralf Goertz <me@myprovider.invalid>: Sep 29 09:01AM +0200

Am Fri, 28 Sep 2018 09:28:30 -0700 (PDT)
 
> The std::byte has all bitwise arithmetic operators defined. What you
> mean by "formatted input"? Sure, when our use case needs something
> extra or different then that can be written.
 
That was the whole point why I started this thread. I need
set<vector<some_integral_type>> e.g. for counting certain permutations.
Sometimes the range of values exceeds what fits in a byte, then I have
to use 16 or 32 bit types. In some cases 8 bit is enough but there are
so many vectors in that set that I get into memory trouble when using 16
bit. That's why I templated my program. Then I fell into the operator
overload trap that cin>>i means something completely different
dependeing on whether i is int or char. I never had to use int8_t before
but as I said I was under the impression, that it would be an integral
and not a char type. Finding out that it is nothing but a typedef to
char made to curious as to what good this typedef does.
 
std::byte seemed promising to me, but as far as I can tell there is
neither a an overload of e.g >>
 
error: no match for 'operator>>' (operand types are 'std::istream' {aka
'std::basic_istream<char>'} and 'std::byte')
 
which I mean by formatted input nor can I do something like b%=42 when b
is a std::byte. That's what I mean by arithmetics.

 
> James Kuyper gave perfect answer to that. Note that exactly because
> of such magical silent promotions and conversions sometimes some code
> will give unexpected diagnostics or results.
 
Thanks, James. But what difference does that make? If the short operands
get promoted to int and the result gets demoted to short, can that
really be different from doing it directly? The program
 
 
#include <iostream>
#include <limits>
 
int main() {
typedef int Int;
Int i1(std::numeric_limits<short int>::max());
Int i2(i1/2);
Int i=i1+i2;
std::cout<<i1<<" "<<i2<<" "<<static_cast<short int>(i)<<std::endl;
}
 
prints
 
32767 16383 -16386
 
here regardless of whether Int is int or short int. Can the observable
behaviour really be different (you said unexpected results)? I get that
the platform may or may not support the addition of shorts directly. But
isn't that merely an implementation detail?
David Brown <david.brown@hesbynett.no>: Sep 29 02:06PM +0200

On 28/09/18 18:28, Öö Tiib wrote:
 
> The std::byte has all bitwise arithmetic operators defined. What you
> mean by "formatted input"? Sure, when our use case needs something
> extra or different then that can be written.
 
I have always thought that was a bad idea. std::byte should have been
pure "raw memory" - a type you can use to read or write anything,
accessing any data for reading and writing (replacing the "char" types
from C for things like memcpy), and being a "pointer to memory". It is
/almost/ such a type, but bitwise operators have no place in such a type.
"Öö Tiib" <ootiib@hot.ee>: Sep 29 05:11AM -0700

On Saturday, 29 September 2018 10:01:35 UTC+3, Ralf Goertz wrote:
> 'std::basic_istream<char>'} and 'std::byte')
 
> which I mean by formatted input nor can I do something like b%=42 when b
> is a std::byte. That's what I mean by arithmetics.
 
These are not there because most sane software does not need those.
Take few steps back, I try once more to explain the big picture that
may help you out of that puzzle (or not). ;)
 
Rules of thumb:
1) For text input/output and for arithmetic processing use only
(u)int32_t, (u)int64_t, double and/or custom fast arithmetic
classes.
 
2) For binary input/output and with large storage use packing
level that is optimal. Optimal may be not to pack at all or
to go down to exact bit positions or even further depending
on bang needed and buck available.
 
The explanations of above rules:
1) When not constrained with I/O then the text formats like
JSON are most convenient. But narrow data types are still bad
for processing. The modern processors do not usually have
instructions for narrow data types. So these have to unpack
from narrow types and later pack back and therefore running
complex computations on narrow types is slower than with
already unpacked fast types. Packed data that is being
under heavy processing cripples.
 
2) The processors are fast on modern platforms so bandwidth and
throughput and latency of communications with anything
(including RAM) can't often feed those with enough data. That is
the common bottle-neck. If that is the case then it can be
profitable to go down to bits or even farther than that
with packing.
However do not reinvent wheels there, use existing formats.
For example most multimedia is packed about 50 times so average
byte of it is packed into about 0.16 bits. For other example
unpacking with the Lempel–Ziv–Welch (LZW) algorithm (Patent
expired on June 20, 2003) can be faster than memcpy() from
unpacked buffer.
 
The conclusions from those points above:
Attempt to read std::byte from text input is breaking all logic!
There are whopping 4 bytes (3 numbers and separator) used in
slow communication that is then turned into inefficient for
processing packed format (a byte). If text is used because of nature
of channel then use Base64 to transferring bytes.
 
 
> Thanks, James. But what difference does that make? If the short operands
> get promoted to int and the result gets demoted to short, can that
> really be different from doing it directly?
 
There is poster supercat in comp.lang.c who loves to post examples
about that. He has only few of those IIRC like that:
 
unsigned mul(unsigned short a, unsigned short b) {return a*b;}
 
The examples of supercat are of interest to me only as stuff that
smells, how to estimate amounts of potential improvements or
simplifications that can be made and likely impact of those.
 
If to follow the "rules of thumb" that I posted above then we
actually do not need these narrow types for anything else
but only when we are constrained with storage or communications.
And then we use these only for converting into larger types
for processing and back for storing. Only sometimes when we
really pack or convert on bit level or further we will need
bitwise operations that std::byte implements for us already.
"Öö Tiib" <ootiib@hot.ee>: Sep 29 05:25AM -0700

On Saturday, 29 September 2018 15:06:31 UTC+3, David Brown wrote:
> accessing any data for reading and writing (replacing the "char" types
> from C for things like memcpy), and being a "pointer to memory". It is
> /almost/ such a type, but bitwise operators have no place in such a type.
 
I see a point of bitwise operations with bytes only for bit-wise
altering the data to fit with some binary layout. That may mean
things like array of 12 bit wide ints packed into a block of bytes
without any padding or results of other such packing algorithms.
Subtracting, adding, multiplying and dividing however feel totally
useless.
"Öö Tiib" <ootiib@hot.ee>: Sep 28 04:33PM -0700

On Saturday, 29 September 2018 01:44:59 UTC+3, Paul wrote:
> It's also not a chocolate biscuit.
 
> It is a design pattern, though.
 
> So I was asking the name of the design pattern.
 
I try to express it then through analogy. Room design patterns are meant
for purpose, for certain activities in those rooms, you know bathroom,
toilet, kitchen, bedroom, living room, studio, garage &c.
Similarly software module design patterns are meant for certain purpose
for running certain algorithms in those modules. Creational design
patterns are for constructing certain types of data, structural design
patterns are for composing relations between objects to acquire
certain functionality and behavioral patterns are also for purpose
usually about communication between objects. So all of it is
about purposeful activities. If there are no purpose then there are
no pattern.
Paul <pepstein5@gmail.com>: Sep 28 05:02PM -0700

On Saturday, September 29, 2018 at 12:33:14 AM UTC+1, Öö Tiib wrote:
> usually about communication between objects. So all of it is
> about purposeful activities. If there are no purpose then there are
> no pattern.
 
The problem is that you have a class B and you want to encapsulate the
idea of "a particular instantiation of class B"
So one idea is to use another class to encapsulate the idea of
"a particular instantiation of class B"
 
So I use class A for that purpose.
 
I'll try to be a bit more concrete --
 
int f(double w, double x, double y, double z)
is an intricate mathematical function
 
B is a class for calculating f.
 
The problem is to illustrate this procedure for the numbers
1.1, 2.3, 4.5, 5.6 -- call the corresponding vector vec.
 
So I write
 
class B
{
public:
B(const std::vector<double>&);

protected:
int f(); // Computes f with respect to 4-dim vector in constructor
};
 
class A : public B
{
 
public:
A();
 
int F();
}
 
A::A() : B(vec)
{
 
}
 
int A::F()
{
return f();
}
 
int main()
{
A a;
std::cout << a.F() << " is the value of f when applied to the
illustrative parameters in vec ";
}
"Öö Tiib" <ootiib@hot.ee>: Sep 28 05:40PM -0700

On Saturday, 29 September 2018 03:02:16 UTC+3, Paul wrote:
> std::cout << a.F() << " is the value of f when applied to the
> illustrative parameters in vec ";
> }
 
Whole class for very concrete instantiation? That is done usually only
in unit tests. So pattern is "mock wrapper for unit testing" or
something like that.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Sep 29 06:46AM

On Fri, 2018-09-28, Paul wrote:
> I have a class A which implements an instantiation of class B with
> some default parameters.
 
I had trouble reading that sentence. How is it different from
"A specializes B, by simplifying its construction"?
 
Also, would a plain function work for you?
 
B A() { return B(C(D(OtherParams))); }
 
...
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Paul <pepstein5@gmail.com>: Sep 29 02:15AM -0700

On Saturday, September 29, 2018 at 7:47:02 AM UTC+1, Jorgen Grahn wrote:
 
> Also, would a plain function work for you?
 
> B A() { return B(C(D(OtherParams))); }
 
> ...
 
I should have said "A specializes B by simplifying its construction."
That's better. Thanks.
 
And thanks to Oo Tiib too
 
And thanks to everyone else.
 
Paul
"😉 Good Guy 😉" <hello.world@example.com>: Sep 29 02:07AM +0100

*Roslyn*is the codename-that-stuck for the open-source compiler for C#
and Visual Basic.NET. Here's how it started in the deepest darkness of
last decade's corporate Microsoft, and became an open source,
cross-platform, public language engine for all things C# (and VB, which
I'll take as a given for the rest of this piece).
 
<https://medium.com/microsoft-open-source-stories/how-microsoft-rewrote-its-c-compiler-in-c-and-made-it-open-source-4ebed5646f98>
 
Good luck.
 
 
--
With over 950 million devices now running Windows 10, customer
satisfaction is higher than any previous version of windows.
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)