Thursday, October 9, 2014

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

comp.lang.c++@googlegroups.com Google Groups
Unsure why you received this message? You previously subscribed to digests from this group, but we haven't been sending them for a while. We fixed that, but if you don't want to get these messages, send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Paul N <gw7rib@aol.com>: Oct 09 03:14PM -0700

I've hit a baffling problem, and I'm not sure if it relates to Windows or to C++.
 
I had the following in my main .cpp file:
 
static SCROLLINFO si;
 
void mySetScrollRangeAndPage(HWND hWnd, int nBar, int nMin, int nMax, UINT nPage) {
si.cbSize = sizeof(si);
si.fMask = SIF_RANGE | SIF_PAGE | SIF_POS;
si.nMin = nMin;
si.nMax = nMax;
si.nPage = nPage;
si.nPos = nMin;
SetScrollInfo(hWnd, nBar, &si, TRUE);
}
 
It worked fine, setting a scroll bar.
 
I wanted to put the scroll bar stuff in a separate file, so that I could use it with other programs. So I copied it to Scroller.cpp, and put the function (but not the definition of si) between lines "namespace Scroller {" and "}". (I admit I'm fairly new to namespaces.) Unfortunately the first call to this function does not work - si is loaded up OK but the scroll bar is not set, it stays at a range of 0 to 100. Later calls seem to work OK so if I do the first one again later everything works, but I can't understand why the first one goes wrong.
 
If I put "SCROLLINFO si;" in the main .cpp file and "extern SCROLLINFO si;" in Scroller.cpp, this also works OK. I don't understand why having it in one .cpp file works and having it in the other doesn't.
 
Can anyone help?
 
I would cross-post to comp.lang.c++ and comp.os.ms-windows.programmer.win32, but Google doesn't seem to do that anymore.
 
Thanks.
Paul.
Barry Schwarz <schwarzb@dqel.com>: Oct 09 04:19PM -0700

On Thu, 9 Oct 2014 15:14:51 -0700 (PDT), Paul N <gw7rib@aol.com>
wrote:
 
>SetScrollInfo(hWnd, nBar, &si, TRUE);
>}
 
>It worked fine, setting a scroll bar.
 
Please set your newsreader to a line length less than 80.
 
>I wanted to put the scroll bar stuff in a separate file, so that I could use it with other programs. So I copied it to Scroller.cpp, and put the function (but not the definition of si) between lines "namespace Scroller {" and "}". (I admit I'm fairly new to namespaces.) Unfortunately the first call to this function does not work - si is loaded up OK but the scroll bar is not set, it stays at a range of 0 to 100. Later calls seem to work OK so if I do the first one again later everything works, but I can't understand why the first one goes wrong.
 
Scroller.cpp should not compile. The name si is unknown during the
compilation phases. How can mySet... change the contents of si in
main.cpp?
 
Adding the line
extern SCROLLINFO si;
will solve the compile problem but create a link problem. Since si in
main.cpp is static, it has internal linkage and its name is never
"exported" to the linker to resolve the name referenced in
Scroller.cpp.
 
>If I put "SCROLLINFO si;" in the main .cpp file and "extern SCROLLINFO si;" in Scroller.cpp, this also works OK. I don't understand why having it in one .cpp file works and having it in the other doesn't.
 
Having it in the other what? Defining a global object with external
linkage in one cpp file and declaring it external in every other cpp
file that needs to access it is the usual technique. Your first
attempt did not do this.
 
>Can anyone help?
 
>I would cross-post to comp.lang.c++ and comp.os.ms-windows.programmer.win32, but Google doesn't seem to do that anymore.
 
Get a real newsreader.
 
--
Remove del for email
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 09 04:22PM -0700

It's possible your packed structure size is
different. Some use 16 byte alignment. Since
it's compiling in two source files, the alignment
could be off causing your member assignment
to be misaligned.
 
Check the compiler switches for packed
structure alignment. Or compare the sizeof()
from both locations. They should be the same.
 
Best regards,
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 09 12:10PM -0700

On Thursday, October 9, 2014 3:03:21 PM UTC-4, Robert Hutchings wrote:
> If you cast an int to an unsigned int, do you lose any of the bits? Are
> any of the bits changed with this cast?
 
You'll have to get a definitive answer from the C++ gurus around here. I
have discovered that my beliefs are often not exactly true with the C/C++
standards because I work with a specific compiler or two and they don't
always follow the standard.
 
I believe you wind up with the unsigned bit equivalent of whatever form
which existed in the signed value. It just now has no respect of sign
in operations. For positive signed int values, it's left exactly as it
is. For negative signed int values it will now be a very large value.
 
Still, it may be implementation specific, or there may be some quirk in
the C/C++ standards I don't know. In testing just now in MSVC++ 2008,
it had no difference. My original int algorithm also worked correctly
on both signed and unsigned inputs. But, as I understand the standard,
that behavior is implementation specific.
 
Best regards,
Rick C. Hodgin
drew@furrfu.invalid (Drew Lawson): Oct 09 07:16PM

In article <o12jgb-hb3.ln1@news.rtij.nl>
>> and 2 virtual functions?
 
>That is completely implementation dependent, but one would expect sizeof
>(int) + sizeof(vtable*) + padding.
 
I would think the key there is that the candidate knows it is
sizeof(vtable*) and not 2*sizeof(function*).
 
 
--
|Drew Lawson | If you're not part of the solution |
| | you're part of the precipitate. |
Martijn Lievaart <m@rtij.nl.invlalid>: Oct 09 10:20PM +0200

On Thu, 09 Oct 2014 19:16:31 +0000, Drew Lawson wrote:
 
>>(int) + sizeof(vtable*) + padding.
 
> I would think the key there is that the candidate knows it is
> sizeof(vtable*) and not 2*sizeof(function*).
 
Which although true for any implementation I know, is implementation
dependent and rather irrelevant imho.
 
M4
Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 09 08:28PM

On Thu, 2014-10-09, Rick C. Hodgin wrote:
> have discovered that my beliefs are often not exactly true with the C/C++
> standards because I work with a specific compiler or two and they don't
> always follow the standard.
 
They probably do, mostly, but the problem is that the standard is more
tolerant than any specific compiler. Google "all the world's a VAX".
 
> which existed in the signed value. It just now has no respect of sign
> in operations. For positive signed int values, it's left exactly as it
> is. For negative signed int values it will now be a very large value.
 
That explanation seems wrong to me, but I'm not very interested in
/what/ happens so I won't try to elaborate.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Ben Bacarisse <ben.usenet@bsb.me.uk>: Oct 09 10:23PM +0100


> On 10/9/2014 1:16 PM, Rick C. Hodgin wrote:
<snip>
 
>> return N_new;
>> }
 
> Yes, this is the algorithm that I found most often on the web.
 
It's more efficient to do it in interleaved blocks, though it gets messy
if you need to make it portable to any int width. For 32 bits:
 
unsigned int reverse_bits(unsigned int n)
{
unsigned int m;
m = n >> 16 | n << 16;
n = (m << 8) & 0xff00ff00 | (m >> 8) & 0x00ff00ff;
m = (n << 4) & 0xf0f0f0f0 | (n >> 4) & 0x0f0f0f0f;
n = (m << 2) & 0xcccccccc | (m >> 2) & 0x33333333;
m = (n << 1) & 0xaaaaaaaa | (n >> 1) & 0x55555555;
return m;
}
 
<snip>
--
Ben.
Paavo Helde <myfirstname@osa.pri.ee>: Oct 09 04:42PM -0500

drew@furrfu.invalid (Drew Lawson) wrote in news:m16muf$1qdn$1
>>(int) + sizeof(vtable*) + padding.
 
> I would think the key there is that the candidate knows it is
> sizeof(vtable*) and not 2*sizeof(function*).
 
I.e. that the candidate knows it is not more harmful to have N>1 virtual
functions in the class than one. If so, why not to ask that directly?
 
p
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Oct 09 11:27PM +0100

On Thu, 09 Oct 2014 14:03:02 -0500
> > Rick C. Hodgin
 
> If you cast an int to an unsigned int, do you lose any of the bits?
> Are any of the bits changed with this cast?
 
Modulo arithmetic is performed for casts to unsigned, so bits are
changed by a cast from signed to unsigned for negative numbers if the
representation of negative signed values is not 2's complement:
 
§4.7/2 of C++11: "If the destination type is unsigned, the resulting
value is the least unsigned integer congruent to the source integer
(modulo 2 n where n is the number of bits used to represent the
unsigned type). [ Note: In a two's complement representation, this
conversion is conceptual and there is no change in the bit pattern (if
there is no truncation). — end note ]"
 
Chris
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 09 02:12PM -0700

The Liberty Software Foundation (LibSF) was created to be an alternative to
other non-God-fearing software organizations. We believe in the foundation
of Jesus Christ in our lives, and we desire to create digital works which
we will give to other people so that they may have better lives, the result
of our labor given unto God, and unto all men who would receive it.
 
The general concept of what the LibSF is involved with in software and
other digital media works is embodied in a larger philosophy called the
Village Freedom Project. This project desires to free us from the
traditional systems of men which are focused upon individual gain at
the expense of others, and instead flips that purpose around to make
our goals the gain of all at the potential expense of the individual
(meaning we give, even sacrificially, to help others who are not
currently in a place where they have what they should, or are able to
do what they should). And this organization refers to the general
concept of "Village" which is a global community. Read more here:
 
Main website:
http://www.libsf.org
 
Village Freedom Project:
http://tinyurl.com/vfreepro
 
I would like to invite people to come and work with me, Rick C. Hodgin, on
these projects that lay ahead.
 
I have long-term goal which consist of these, and others:
 
(1) Exodus Operating System, a new from the ground-up i386-based OS.
URL: https://github.com/RickCHodgin/libsf-full/tree/master/_exodus
URL: http://www.libsf.org:7990/projects/LIB/repos/libsf-full/browse/_exodus
OGV: http://www.visual-freepro.org/videos/2014_02_13__exodus_debi_debugger.ogv
 
(2) Visual FreePro, which includes Visual FreePro, Jr., the Rapid
Development C/C++ Compiler (RDC), the Debi and JDebi debuggers, and
a new virtual machine called VVM (the Visual FreePro Virtual Machine).
URL: http://www.visual-freepro.org/indexmain.html
URL: http://www.visual-freepro.org/vjr/indexmain.html
ZIP: http://www.libsf.org/software/vjr_0.53.zip
Screenshot: http://www.visual-freepro.org/images/vjr_053.png
 
(3) Porting the x86-based Exodus to the ARM CPU, under the name Armodus.
 
(4) Coming back to Exodus and creating Exodus-64.
 
(5) Coming back to Armodus and creating Armodus-64.
 
We also have other project slated for development and completion:
URL: http://www.libsf.org/projects
 
(6) Whitebox, a non-linear video and audio editor, one designed to take
raw video and audio content, a database of edits, and apply on-the-fly
fixups to remove or obscure content so that scenes which are offensive
to some are no longer presented, or are altered by swapping out scenes,
images, portions of scenes, audio tracks, blurring, color bars, and more.
 
(7) Boost, a simple dice-rolling game with the goal being to better
your opponents score ahead of your own. You "give them a boost."
 
(8) TimeBank, a way to envision a calendar system by looking at the
time you have allotted to your life in terms of a bank, that there
are no additional deposits, and that every day which goes by is only
a withdrawal, and that each day should be made the most of.
 
(9) Anchor, a git-like version control system which is made for ease
of use, and one which readily maintains past "anchors" of changes made,
by file, by time, by project, and more.
 
(10) Interface, a replacement for the web-browser built around Visual
FreePro's client/server and remote data connectivity abilities, which
allow for applications to be constructed which access data locally, or
remotely, using forms which are stored locally, or remotely. In short,
it is a way to create websites which aren't merely used in browser, but
are real apps that can be viewed over a network as though they were a
browser, but can also be stored locally allowing full access to the
website's features, but on a local copy.
 
-----
In support of these projects LibSF plans to create an AppHome which will
hold all software available for download, including source code, binary
executables, documentation, multimedia content, and more. In addition
there will be a system created which allows people to click a "Donate"
button and give monetarily the project authors. LibSF will take no
percentage of any transaction, but will also have its own "Donate"
button. The LibSF AppHome will be sponsored by the generosity of those
who desire to give unto God, and unto men, from their own bosom. And
should anyone wish to give back, the facility will be there.
 
-----
LibSF would also like to sponsor "Community Bees," where those who
work on the same project could get together and have meetups. Nothing
fancy or elaborate, but if you've got a relative with a barn and a place
to setup tents for the weekend, then people can come together, enjoy fun
and fellowship, make new friends, meet new people, learn new things, and
enjoy something like a campfire good time, all related to the project
you're interested in, with others of similar interests.
 
-----
LibSF is purposed to be a long-term project, and one which seeks from
its absolute core to nothing less than a service, a labor of love unto
the Lord, and unto people. It was started in July, 2012. To date I
have had one other person working with me, a Spanish speaking man from
Columbia. He has contributed where he can, but he is not a C/C++
developer. I need more developers to see this vision through.
 
I would like to invite everyone who would like to be a part of this
offering unto Jesus Christ with their life, to come forward and we'll
start building our future together, His Kingdom here upon this Earth,
as part of LibSF, the Village Freedom Project, and the brotherhood and
sisterhood of those who are redeemed, awaiting our Lord's soon return:
 
"In God's sight, we've come together.
We've come together to help each other.
Let's grow this project up ... together!
In service and Love to The Lord, forever!"
 
Thank you, and may the Lord lead you to contribute to the fullest
extent of your abilities on this, or other projects. May your light
shine for Him upon this Earth. And may He receive the fullest return
on all that He first endowed you with in this world, that you may
hear those words, "Well done, my good and faithful servant," upon
your departure from this temporary world.
 
A brother in Christ,
Rick C. Hodgin
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 09 10:18PM +0100

On 09/10/2014 22:12, Rick C. Hodgin wrote:
> your departure from this temporary world.
 
> A brother in Christ,
> Rick C. Hodgin
 
Evolution is proof that your software is the work of the deluded. Your
god doesn't exist mate and your various attempts to preach in this ng
are not welcome.
 
/Flibble
"Charles J. Daniels" <chajadan@gmail.com>: Oct 08 04:42PM -0700

On Wednesday, October 8, 2014 12:28:56 PM UTC-7, Mark wrote:
 
> std::streamsize const streamLen
 
> = iss.rdbuf()->in_avail();
 
> But streamLen is always zero.
 
istream let's you read in chunks at a time in the size you specify, so you could read in 10k at a time, accumulate the input until done, and if you hit your absolute limit, choose to stop. So if your only concern was a max limit, that's fully covered depending on how you grab the data out of the stream. if you can use istream::read, that would do it
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)