Thursday, November 6, 2014

Digest for comp.lang.c++@googlegroups.com - 22 updates in 7 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.
ram@zedat.fu-berlin.de (Stefan Ram): Nov 06 11:27PM

> Ipv4Address IPaddr;
> };
>typedef std::list<struct MappingTable> MAPTble;
 
The »struct MappingTable« might actually be a »MappingRow«.
 
>I want to hard code the GUID address column and the other one
 
»hardcode« or »hard-code«.
 
>just remain an empty , on request I want to fill it. please
>tell me how to write the code in its .cc file?
 
Maybe along the following lines?
 
#include <list>
struct pair { int a; int b; };
int main(){ ::std::list< pair >l{ { 454, 0 },{ 2935, 0 },{ 5, 0 }}; }
 
Or maybe
 
#include <list>
int main()
{ ::std::list< int >const a{ 454, 2935, 5 };
::std::list< int >b( 3 ); }
 
This is the meaning of »hardcode«: Fix something in the source code.
 
>one thing more I want to call this list in constructor as well.
 
The callable entities in C++ are functions, functors,
and macros IIRC. IIRC, lists are not called.
"K' Dash" <adnanrashidpk@gmail.com>: Nov 06 01:14PM -0800

Hello All
 
I want to hard code the link list., please see the figure
________________________
|GUID_address|IPaddress|
| | |
| | |
| | |
| | |
------------------------
 
I wrote this code in header (.h)file:
******************************************************************************
bool GetMatchingGUID (GUID_address guidaddress,Ipv4Address currentIP);
 
struct MappingTable
{
GUID_address GUIDaddr;
Ipv4Address IPaddr;
};
typedef std::list<struct MappingTable> MAPTble;
typedef std::list<struct MappingTable>::iterator MAPTbleI;
MAPTble m_mappingTable;
******************************************************************************
I want to hard code the GUID address column and the other one just remain an empty , on request I want to fill it. please tell me how to write the code in its .cc file?
one thing more I want to call this list in constructor as well.
Christopher Pisz <nospam@notanaddress.com>: Nov 06 03:40PM -0600

On 11/6/2014 3:14 PM, K' Dash wrote:
 
Not really sure what you are looking for.
Maybe this?
 
class Something
{
std::map<GUID_address, shared_ptr<Ipv4Address> m_map;
 
public:
Something()
{
shared_ptr<Ipv4Address> uninitialized;
m_map[GUID_address("1")] = uninitialized;
m_map[GUID_address("2")] = uninitialized;
}
 
 
void Later()
{
m_map[GUID_address("2")] = shared_ptr<Ipv4Address>(new
Ipv4Address());
}
};
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Nov 06 09:43PM

On 06/11/2014 21:40, Christopher Pisz wrote:
> Ipv4Address());
> }
> };
 
One should prefer unique_ptr to shared_ptr; only use shared_ptr if you
want sharing semantics.
 
/Flibble
Christopher Pisz <nospam@notanaddress.com>: Nov 06 03:57PM -0600

On 11/6/2014 3:43 PM, Mr Flibble wrote:
 
> One should prefer unique_ptr to shared_ptr; only use shared_ptr if you
> want sharing semantics.
 
> /Flibble
 
Hard to tell without more requirement details. I assume he wants a
lookup for others to get a hold of the Ipv4 Address, store it, and use
it, so I went with shared_ptr. I'm just going by the name if the thing.
DSF <notavalid@address.here>: Nov 06 03:32PM -0500

Hello, group!
 
In the string template class I've been writing, I have one data
member that is static (and constant). It is called "blank" and is
used as data for an empty string. The declaration is as follows:
 
template <class CH> class FString
{
...
private:
static const uint blank;
};
Where uint is a typedef for unsigned integer.
 
Near the end of FString.h, I have the following:
 
template <class CH> const uint FString<CH>::blank = 0;
 
I wondered if this would link without duplicate "blank" errors, it
did link.
 
I assume each instance of FString within a given TU will use the
same "blank".
 
My question is, will every translation unit (TU) including FString.h
have a separate "blank" in its data segment, or will there be just one
for the entire program?
 
Thanks,
DSF
"'Later' is the beginning of what's not to be."
D.S. Fiscus
Victor Bazarov <v.bazarov@comcast.invalid>: Nov 06 03:46PM -0500

On 11/6/2014 3:32 PM, DSF wrote:
 
> My question is, will every translation unit (TU) including FString.h
> have a separate "blank" in its data segment, or will there be just one
> for the entire program?
 
I remember reading that the linker will take into consideration the fact
that they all (in all TUs that refer to that symbol *and* define it) of
the same type and are *supposed to be* the same object, and will keep
only one. IOW, it's not a violation of ODR to have a definition and
initialization of a static member of a class template in the header.
 
V
--
I do not respond to top-posted replies, please don't ask
Paavo Helde <myfirstname@osa.pri.ee>: Nov 06 03:25PM -0600

DSF <notavalid@address.here> wrote in
 
> My question is, will every translation unit (TU) including FString.h
> have a separate "blank" in its data segment, or will there be just one
> for the entire program?
 
'Data segment' is not a term which comes up in the standard. Translated
to the standardese, your question is: do the static data members of a
class template have internal or external linkage?
 
I think this is covered by:
 
14/4: A template name has linkage (3.5). A non-member function template
can have internal linkage; any other template name shall have external
linkage.
 
3.4.6/5: a [...] static data member [...] has external linkage if the
name of the class has external linkage.
 
If it were not constant, then I think this means the compiler+linker have
to guarantee there is exactly one 'blank' for each different instantiated
type CH, but with const I guess the rules are a bit relaxed. In
particular, the compiler can choose to optimize it fully away so there is
no space taken in any data segment, or to collide them all together so
there is only a single 'blank' for all instantiations and all TU-s.
 
Cheers
Paavo
Marcel Mueller <news.5.maazl@spamgourmet.org>: Nov 06 06:58PM +0100

On 06.11.14 00.26, Luca Risolia wrote:
>> key/?
 
> Rehashing and other operations that internally change the order of
> elements preserve the relative order of elements with equivalent keys.
 
Is this experience or guaranteed?
 
 
Marcel
Marcel Mueller <news.5.maazl@spamgourmet.org>: Nov 06 07:09PM +0100

I should add some more details.
 
I want to build up a list of entries with two keys. The first key is an
identifier name, i.e. string. Lookups for this key are always exact
matches. So a hash table is the first choice.
 
The second key is a version number (int). This is used if the same
identifier is redefined in a nested scope shadowing the outer
definition. (It is part of a compiler.)
If the unordered_multimap keeps the sequence then the entries are always
ordered by the second key, because they are always added strongly
monotonically. So I can easily use one of the borders of equal_range to
get the most recent version.
 
Using a nested structure with map inside unordered_map is not my first
choice because it is very likely that most of the identifiers never get
more than one version. And so I get very many maps with only one element
which is not that efficient.
 
 
Marcel
Luca Risolia <luca.risolia@linux-projects.org>: Nov 06 09:12PM +0100

Il 06/11/2014 18:58, Marcel Mueller ha scritto:
 
>> Rehashing and other operations that internally change the order of
>> elements preserve the relative order of elements with equivalent keys.
 
> Is this experience or guaranteed?
 
Both. Here is the guarantee from the standard:
 
23.2.5 Unordered associative containers
 
"In containers that support equiv-
alent keys, elements with equivalent keys are adjacent to each other in
the iteration order of the container.
Thus, although the absolute order of elements in an unordered container
is not specified, its elements are
grouped into
equivalent-key group
s such that all elements of each group have equivalent keys. Mutating
operations on unordered containers shall preserve the relative order of
elements within each equivalent-key
group unless otherwise specified."
woodbrian77@gmail.com: Nov 06 09:15AM -0800

I was reviewing some code and believe I found a problem.

template <class T, class B>
void complexMarshal (B& buf, ::std::complex<T> const& cmplx)
{
buf.Receive(cmplx.real());
buf.Receive(cmplx.imag());
}
 
// No problem yet
 
template <class T, class B>
::std::complex<T> complexGive (B& buf)
{
return ::std::complex<T>(buf.template Give<T>(), buf.template Give<T>());
}
 
There though since the order of evaluation of the
arguments isn't defined it could stick the value for
real into the imaginary field and vice versa. I've
read about this issue for years, but never had to deal
with it until now.
 
Here's the way I've thought of to fix it:
 
template <class T, class B>
::std::complex<T> complexGive (B& buf)
{
auto rl = buf.template Give<T>();
return ::std::complex<T>(rl, buf.template Give<T>());
}
 
Is there a better way to fix it? And how about a suggestion
for a comment to help prevent someone from accidentally
undoing the fix?
 
Brian
Ebenezer Enterprises - So far G-d has helped us.
http://webEbenezer.net
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Nov 06 07:18PM

> auto rl = buf.template Give<T>();
> return ::std::complex<T>(rl, buf.template Give<T>());
> }
 
A proper fix would be to have "Give()" use an out parameter rather than
a return value thereby preventing the problem from occurring in the
first place. A nice side-effect of this way of doing things is that you
don't need that horrible extra template keyword syntax as T can be
deduced from the output argument.
 
/Flibble
woodbrian77@gmail.com: Nov 06 11:31AM -0800

On Thursday, November 6, 2014 1:18:54 PM UTC-6, Mr Flibble wrote:
 
> A proper fix would be to have "Give()" use an out parameter rather than
> a return value thereby preventing the problem from occurring in the
> first place.
 
I think that would have the same problem.
 
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Nov 06 07:46PM

>> a return value thereby preventing the problem from occurring in the
>> first place.
 
> I think that would have the same problem.
 
Think again.
 
/Flibble
Tony Jen <tonyjen0905@gmail.com>: Nov 06 04:48AM -0800

On Monday, October 6, 2014 2:46:14 PM UTC-4, Richard wrote:
> The Computer Graphics Museum <http://computergraphicsmuseum.org>
> The Terminals Wiki <http://terminals.classiccmp.org>
> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
 
 
Currently the page says the page is not loading pending permission from Bjarne.
agent@drrob1.com: Nov 05 06:49PM -0500

On Tue, 04 Nov 2014 20:35:12 -0800, Barry Schwarz <schwarzb@dqel.com>
wrote:
 
>the value is or is not NULL.
 
>>I tried atoi and type casting, but I don't understand this well enough
>>yet.
 
Thanks, this helped. I was able to do this with a segfault
i = intptr_t ( argv[argc] );
 
and i has the value of 0.
 
I guess what I'm having so much trouble with is how pervasive pointers
are in c-ish. Modula-2 and Ada don't do this.
 
I thought that argv[argc] is just a byte that I could have
interpretted in a different way. I now understand that the compiler
sees this as a pointer type and I cannot easily change that.
 
Thanks again.
Rob
agent@drrob1.com: Nov 05 06:49PM -0500

On Wed, 5 Nov 2014 08:55:43 -0500, "Osmium" <r124c4u102@comcast.net>
wrote:
 
 
>As I post this I have read the answers I can see on my server at 13:50 GMT
>on Wednesday.
 
>http://icecube.wisc.edu/~dglo/c_class/stdio.html
 
That link is helpful. Thanks
Barry Schwarz <schwarzb@dqel.com>: Nov 05 09:56PM -0800

>>>yet.
 
>Thanks, this helped. I was able to do this with a segfault
> i = intptr_t ( argv[argc] );
 
This should not have caused a seg fault since you are not attempting
to dereference the pointer. Evaluating a NULL pointer is perfectly
legal.
 
But the conversion is completely unnecessary. Everything you can
learn from i can be just as easily, and more efficiently, handled with
the expression
argv[argc] == NULL
and if the concept of NULL is bothering you then you can use the
equivalent
argv[argc] == 0
 
>and i has the value of 0.
 
An implementation detail specific to your compiler (also common to
many other compilers) but not guaranteed to be portable.
 
 
>I thought that argv[argc] is just a byte that I could have
>interpretted in a different way. I now understand that the compiler
>sees this as a pointer type and I cannot easily change that.
 
It is the start-up code that gets control before your main function
that passes the arguments to main. It will always pass an int as the
first argument (which convention calls argc but there is nothing
magical about the name). The start-up code also constructs an array of
argc+1 pointers: the first pointer (known as argv[0]) points to an
implementation defined string which identifies the program; the next
argc-1 pointers point to the arguments, if any, from the command line
that was used to invoke the program; and the last pointer (known as
argv[argc]) will be set to NULL. The start-up code passes the address
of the first of these constructed pointers as the second argument.
 
--
Remove del for email
Geoff <geoff@invalid.invalid>: Nov 06 12:32AM -0800

On Wed, 05 Nov 2014 10:27:59 -0800, Barry Schwarz <schwarzb@dqel.com>
wrote:
 
 
>>It's wrong because the /address of/ argv[argc][0] at that time is
>>NULL. It points to nothing, therefore you can't dereference it.
 
>Surely you meant the address in argv[argc].
 
I mean both. If argv[argc] is NULL, then argv[argc][0], the pointer to
what would be the first member of the argv[argc] array is also NULL,
therefore the dereference of that pointer is a segfault.
 
If the OP's program is passed no command line arguments then argc == 1
and argv[argc] == NULL, dereferencing it with argv[argc][0] must fail.
 
[snip]
 
 
>The address of a pointer is the address in memory that the pointer
>occupies. It is obtained by applying the & operator to the pointer
>name.
 
Quite right. If he had written if(&argv[argc][0] != NULL) ch =
argv[argc][0]; he would have avoided the segfault but that's probably
a little too defensive to suit most c++ programmers and probably not
what the OP is seeking.
 
Barry Schwarz <schwarzb@dqel.com>: Nov 06 02:25AM -0800

On Thu, 06 Nov 2014 00:32:51 -0800, Geoff <geoff@invalid.invalid>
wrote:
 
 
>I mean both. If argv[argc] is NULL, then argv[argc][0], the pointer to
>what would be the first member of the argv[argc] array is also NULL,
>therefore the dereference of that pointer is a segfault.
 
Since argv[i] has type char*, it is obvious that argv[i][0] has type
char is not a pointer at all.
 
>>name.
 
>Quite right. If he had written if(&argv[argc][0] != NULL) ch =
>argv[argc][0]; he would have avoided the segfault but that's probably
 
No, this would not avoid the seg fault. The [] operator binds more
tightly than the & operator and the expression &argv[argc][0]
evaluates as &(argv[argc][0]) and that involves derefencing argv[argc]
which is NULL and therefore cannot be dereferenced.
 
 
--
Remove del for email
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Nov 06 03:07AM -0800

int main (int argc, char* argv[])
{
char ch;
 
ch = argv[argc - 1][0];
// this line gives a seg fault return 0;
}
 
The top ten things I hate most about C/C++:
 
#9 ... #8 ... ... ... #1 ... #0.
 
Best regards,
Rick C. Hodgin
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)