vector<pair> .. more

[ma740988]

Consider:
# include <iostream>
# include <string>
# include <map>
# include <bitset>
# include <vector>

using namespace std;

typedef unsigned char* ADDR_TYPE;
typedef unsigned int uint_type;
uint_type const NUM_PROC(4);

int CNum2(2);
// Go back to Josuttis and see if I got the right candidate for teh Job
// for now a vector of pairs ...
typedef std::pair < unsigned int, std::vector<int> > Mypair;
typedef std::vector< Mypair > myVecPair;

void card2_func( myVecPair& refVec ) // give this function the array
{
int mask(0x10);
if (refVec.size())
{
refVec.clear();
}
uint_type SZ(NUM_PROC * CNum2);
int size(5);

for (int idx(0); idx < 2; ++idx)
{
uint_type lMask = 0x00000001 << (NUM_PROC*(CNum2-1));
uint_type nContor(NUM_PROC * (CNum2 - 1));

bool found_match(false);
for (; nContor < SZ; nContor++)
{
if (mask & lMask)
{
int val = mask & lMask;
refVec[idx].second.push_back(nContor);
printf(" %d\n", nContor);
found_match = true;
}
lMask <<= 1;
}
mask += 0x1;
if ( found_match )
{
refVec[idx].first = size;
}
size += 1;
// cout << " OK " << std::endl;
}
}

int main()
{
myVecPair mV;
card2_func(mV);
for (int idx(0); idx < mV.size(); ++idx)
{
std::cout << mV[idx].first << std::endl;
for (int jdx(0); jdx < mV[idx].second.size(); ++jdx)
{
// std::cout << mV[idx].second.[jdx] << std::endl;
}
}
return 0;
}

At issue: I'm having difficulties trying to access the mV 'second'
elements within main. See commented out line.
2/
I need to pull out the texts again for a pointer refresher. I'm using
unsigned char* for doing pointer arithmetic.

So now:
typedef unsigned char* ADDR_TYPE;
int Var(0xD0000000); // known address on PCI bus.
ADDR_TYPE ptr = (ADDR_TYPE)Var;

ptr is a unsigned char pointer. The variable Var is an integer. When
I cast Var to ptr. I'm getting the address of Var. But Var is is an
integer. So the cast to ptr would need enough memory to hold a Var.
I'm tring to determine when ptr would overflow?

[James Aguilar]

It seems to me like there should not be a . between "mv[idx].second"
and "[jdx]". If you do want to have a ., I think it should be
".operator [](jdx)".

I don't know anything about your second question.

[Victor Bazarov]

ma740988 wrote:

Consider:
# include <iostream>
# include <string>
# include <map>
# include <bitset>
# include <vector>

using namespace std;

typedef unsigned char* ADDR_TYPE;
typedef unsigned int uint_type;
uint_type const NUM_PROC(4);

int CNum2(2);
// Go back to Josuttis and see if I got the right candidate for teh Job
// for now a vector of pairs ...
typedef std::pair < unsigned int, std::vector<int> > Mypair;
typedef std::vector< Mypair > myVecPair;

void card2_func( myVecPair& refVec ) // give this function the array
{
int mask(0x10);
if (refVec.size())
{
refVec.clear();
}
This is just redundant. If you need to clear, then clear. If it's empty
already, 'clear' has no effect.
uint_type SZ(NUM_PROC * CNum2);
int size(5);

for (int idx(0); idx < 2; ++idx)
{
uint_type lMask = 0x00000001 << (NUM_PROC*(CNum2-1));
uint_type nContor(NUM_PROC * (CNum2 - 1));

bool found_match(false);
for (; nContor < SZ; nContor++)
{
if (mask & lMask)
{
int val = mask & lMask;
refVec[idx].second.push_back(nContor);
printf(" %d\n", nContor);
found_match = true;
}
lMask <<= 1;
}
mask += 0x1;
if ( found_match )
{
refVec[idx].first = size;
}
size += 1;
// cout << " OK " << std::endl;
}
}

int main()
{
myVecPair mV;
card2_func(mV);
for (int idx(0); idx < mV.size(); ++idx)
{
std::cout << mV[idx].first << std::endl;
for (int jdx(0); jdx < mV[idx].second.size(); ++jdx)
{
// std::cout << mV[idx].second.[jdx] << std::endl; .. ^^^
.. What's the dot doing there?
}
}
return 0;
}

At issue: I'm having difficulties trying to access the mV 'second'
elements within main. See commented out line.
What kind of difficulty?
2/
I need to pull out the texts again for a pointer refresher. I'm using
unsigned char* for doing pointer arithmetic.

So now:
typedef unsigned char* ADDR_TYPE;
int Var(0xD0000000); // known address on PCI bus.
ADDR_TYPE ptr = (ADDR_TYPE)Var;

ptr is a unsigned char pointer. The variable Var is an integer. When
I cast Var to ptr. I'm getting the address of Var.
Really? What proof do you have?
But Var is is an
integer. So the cast to ptr would need enough memory to hold a Vr.
What?
I'm tring to determine when ptr would overflow?

Is that a question? Please start it with a verb or a special word.

V

[ma740988]

Ok.. Thanks all.
Victor, I have to re-think what the heck I was asking on that second
question. I don't do too well with trying to convey my thoughts when
dealing with C++.

[Neil Cerutti]

On 2005-12-14, ma740988 <ma******@gmail.com> wrote:

Consider:
# include <iostream>
# include <string>
Not used.
# include <map>
You do not need <map> for std::pair. #include <utility> instead.
# include <bitset>
Not used.
# include <vector>

using namespace std;

typedef unsigned char* ADDR_TYPE;
typedef unsigned int uint_type;
uint_type const NUM_PROC(4);
I'm confused by your naming conventions. In particular, all-caps
should be reserved for evil macros.
int CNum2(2);
// Go back to Josuttis and see if I got the right candidate for teh Job
// for now a vector of pairs ...
typedef std::pair < unsigned int, std::vector<int> > Mypair;
typedef std::vector< Mypair > myVecPair;
And yet another name convention appears. Why is it Mypair and
myVecPair? That makes no sense.

Seriously, the wildly varying convention for names makes this
code harder to understand that it needs to be.
void card2_func( myVecPair& refVec ) // give this function the array
{
int mask(0x10);
if (refVec.size())
{
refVec.clear();
}
Just clear it if you want to clear it. There's no need to check
it's already empty.
uint_type SZ(NUM_PROC * CNum2);
int size(5);

for (int idx(0); idx < 2; ++idx)
{
uint_type lMask = 0x00000001 << (NUM_PROC*(CNum2-1));
uint_type nContor(NUM_PROC * (CNum2 - 1));

bool found_match(false);
for (; nContor < SZ; nContor++)
{
if (mask & lMask)
{
int val = mask & lMask;
refVec[idx].second.push_back(nContor);
printf(" %d\n", nContor);
found_match = true;
}
lMask <<= 1;
}
mask += 0x1;
if ( found_match )
{
refVec[idx].first = size;
}
size += 1;
// cout << " OK " << std::endl;
}
}
I hope there's no bug in the above, because it doesn't seem worth
the efford to understand it.
int main()
{
myVecPair mV;
card2_func(mV);
for (int idx(0); idx < mV.size(); ++idx)

I'm hating your use of the constructor syntax for initializing
built-in types. I strongly encourage the idiomatic "int idx = 0"
to avoid confusing-looking code. In addition, your going to find
yourself accidentally declaring functions some of the time if you
keep it up. ;-)

In the case of your nested loops, using iterators instead of
indexing will be a greatly improvement, and speed things up, too.

You probably wnat '\n' instead of std::endl in this code, as a
std::endl after every output defeats the whole purpose using a
buffered output stream.

for(myVecPair::iterator i = mV.begin(); i != mV.end(); ++i)
{
std::cout << i->first << '\n';
for (vector<int>::iterator j = i->second.begin();
j != i->second.end(); ++j)
{
std::cout << *j << '\n';
}
}

--
nCerutti (or is it Ncerutti or nC or NEIL_CERUTTI? I shall let
fate decide) ;-)

[ma740988]

Neil, I realize what you're saying, nonetheless realize it's just 'test
code'. The names used dont reflect what my real code. In other
words, the superfluous string etc.. etc. is only there becasue I was
doing 'other test' that's not shown. The naming convention and all -
is again part of test code. In my real code I have meaningful names.
I agree, that it - perhaps - makes things slightly harder to read at
the newsgroup level but the intent at the newsgroup level is to:
1. post the smallest amount of - preferably compilable source.
2. highlight the arrea of code where I'm having difficulties.

Love the comments that you and Victor allude to with respect to:
1. No need to check size. Call clear directly.
|| I'm hating your use of the constructor syntax for initializing
built-in types.
This a new one for me but, I'll take that into consideration.

|| In the case of your nested loops, using iterators instead of
indexing will be a greatly improvement, and speed things up, too
Agreed

|| In particular, all-caps should be reserved for evil macros.
I never fully understood this. Is this a programming rule or ??

[Marcus Kwok]

ma740988 <ma******@gmail.com> wrote:

|| In particular, all-caps should be reserved for evil macros.
I never fully understood this. Is this a programming rule or ??

Not a rule, but a convention that helps to avoid name conflicts. If you
stick to this convention, then the likelihood of a macro unexpectedly
changing your code can be minimized.

--
Marcus Kwok

[Neil Cerutti]

On 2005-12-15, ma740988 <ma******@gmail.com> wrote:

Neil, I realize what you're saying, nonetheless realize it's
just 'test code'. The names used dont reflect what my real
code. In other words, the superfluous string etc.. etc. is
only there becasue I was doing 'other test' that's not shown.
The naming convention and all - is again part of test code. In
my real code I have meaningful names. I agree, that it -
perhaps - makes things slightly harder to read at the newsgroup
level but the intent at the newsgroup level is to:
1. post the smallest amount of - preferably compilable source.
2. highlight the arrea of code where I'm having difficulties.
OK. But remember that clearer code will elicit clearer help. ;-)
When putting together sample code to post, following exemplary
coding practices will imrove your chances of getting a helpful
reply.
Love the comments that you and Victor allude to with respect to:
1. No need to check size. Call clear directly.
|| I'm hating your use of the constructor syntax for initializing
built-in types.
This a new one for me but, I'll take that into consideration.

It's just a matter of convention and opinion; others may not
agree with me. But I found

for (int idx(0); idx < mV.size(); ++idx)

confusing at first, even though its meaning is clear enough after
briefly thinking about it. I just don't want to need to think
about it.

--
Neil Cerutti