Inexplicable error with std::string

D

Dave

Can anybody tell me why the code below should produce the error below? I'm
going nuts here! Am I missing something incredibly obvious and simple?

std::string::size_type idx;
std::string one_line;
..
..
..
idx = one_line.find('\t', 0);


error C2059: syntax error : 'constant'
 
J

John Carson

Dave said:
Can anybody tell me why the code below should produce the error
below? I'm going nuts here! Am I missing something incredibly obvious
and simple?

std::string::size_type idx;
std::string one_line;
.
.
.
idx = one_line.find('\t', 0);


error C2059: syntax error : 'constant'


Try supplying a complete compileable sample that produces the error. The
three lines you have supplied compile fine with both VC++ 2002 and Comeau
online.
 
D

Dave

John Carson said:
Try supplying a complete compileable sample that produces the error. The
three lines you have supplied compile fine with both VC++ 2002 and Comeau
online.

I don't know if this will help, but here's the full function. However, to
provide enough context to make it fully compileable would draw in thousands
of lines of code. So, this is the best I can do, but I understand if it's
not enough context and doesn't help... (BTW my platform is VC++ 7.1, but I
suppose that shouldn't matter; famous last words...)

void Sell::ChangeSale()
{
std::string::size_type first_char;
std::string::size_type idx;
std::string::size_type last_char;
int num_tabs;
std::string one_line;
std::string percent;
int total(0);

for (int i = 0; i < mVisibleMatchUps_psxListBox->count(); ++i)
{
one_line = std::string(mVisibleMatchUps_psxListBox->text(i));
num_tabs = std::count(one_line.begin(), one_line.end(), '\t');

if (num_tabs < 7)
continue;

idx = one_line.find('\t', 0);
first_char = idx + 1;
last_char = one_line.find('\t', first_char) - 1;

if (last_char < first_char)
continue;

percent = one_line.substr(first_char, last_char - first_char + 1);
total += atoi(percent.c_str());

}

mVisibleMatchUps_psxListBox->storeData() ;
DeleteSale() ;
AddSale() ;
}//ChangeSale(...
 
D

Dave

Ron Natalie said:
]> .
idx = one_line.find('\t', 0);
Try sticking an #undef find before this line. The line looks fine, could be some joker
redefined find.

$%&#^!*#$#*!$& (repeat 100 times)!!!!!

That actually was the problem! Man, I could just scream trying to maintain
the code base for the project I'm on. This is the most God-awful piece of
programming I've ever seen, and there are 300,000 lines of this nonsense!
The programmers that did this and the managers that allowed this and
everything else that's wrong with this app. to happen should all be
summarily executed...

Thanks, I think you just saved my sanity! (But it's doomed eventually anyway
since I'll have to continue to work on this project!)
 
C

Cy Edmunds

Dave said:
Ron Natalie said:
]> .
idx = one_line.find('\t', 0);
Try sticking an #undef find before this line. The line looks fine, could be some joker
redefined find.

$%&#^!*#$#*!$& (repeat 100 times)!!!!!

That actually was the problem! Man, I could just scream trying to maintain
the code base for the project I'm on. This is the most God-awful piece of
programming I've ever seen, and there are 300,000 lines of this nonsense!
The programmers that did this and the managers that allowed this and
everything else that's wrong with this app. to happen should all be
summarily executed...

Thanks, I think you just saved my sanity! (But it's doomed eventually anyway
since I'll have to continue to work on this project!)

Ron made a great call here. It goes to show you why I hate C macros so much.
As BS once commented, they make what the compiler sees different from what
you see. How can that be good?
 
J

Jeff Schwab

$%&#^!*#$#*!$& (repeat 100 times)!!!!!

That actually was the problem!

Okay, *that's* impressive.

Ron, are you actually the author of the dubious code in question?

;),
Jeff
 
P

P.J. Plauger

Ron made a great call here. It goes to show you why I hate C macros so much.
As BS once commented, they make what the compiler sees different from what
you see. How can that be good?

Maybe the compiler doesn't recognize the same dialect that you want
to speak. I agree that macros can be abused, and the OP has presented
an extreme case of such abuse. But the irony is that C++ has spawned
so many dialects over the past decade that implementors *must* make
extensive use of the preprocessor to cope.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
 
R

Ron Natalie

Jeff Schwab said:
Okay, *that's* impressive.

Ron, are you actually the author of the dubious code in question?

Nope, I looked up the error in the Microsoft docs. Then I thought about how the
above syntax could gag on the '\t' or 0 literals and the only way I could think of was
if find() were NOT a function.
 
C

Cy Edmunds

P.J. Plauger said:
Maybe the compiler doesn't recognize the same dialect that you want
to speak. I agree that macros can be abused, and the OP has presented
an extreme case of such abuse. But the irony is that C++ has spawned
so many dialects over the past decade that implementors *must* make
extensive use of the preprocessor to cope.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

Absolutely no argument here.
 
J

Jeff Schwab

Cy said:
Absolutely no argument here.

I didn't realize the situation was that bad. I'm sure this is a
hopelessly naive question, but... What's wrong with complying (as
closely as possible) with the most recent standard, and providing flags
for compatibility with the most common dialects?
 
C

Cy Edmunds

Jeff Schwab said:
I didn't realize the situation was that bad. I'm sure this is a
hopelessly naive question, but... What's wrong with complying (as
closely as possible) with the most recent standard, and providing flags
for compatibility with the most common dialects?

Nothing, if that's all there was to it. Check out the macro spaghetti at the
top of various library code (standard library, boost, etc.) and see what
these poor guys have to put up with in order to get their code to compile
across platforms and compilers. It's brutal.

I'm opposed to the preprocessor if there is any reasonable alternative but
you do what you gotta do...
 
J

Jeff Schwab

Cy said:
Nothing, if that's all there was to it. Check out the macro spaghetti at the
top of various library code (standard library, boost, etc.) and see what
these poor guys have to put up with in order to get their code to compile
across platforms and compilers. It's brutal.

I'm opposed to the preprocessor if there is any reasonable alternative but
you do what you gotta do...

I see what you mean. So, the problem isn't so much with dialects of
C++, but with portability across platforms?
 
C

Cy Edmunds

Jeff Schwab said:
I see what you mean. So, the problem isn't so much with dialects of
C++, but with portability across platforms?

That and compilers, which have far more "personality" than the standard
allows. :) I guess that counts as dialects. There are other problems too,
like calling sequences, various non-standard declarations required to
compile DLL's, mumble mumble ...

I'm the wrong guy to ask though. My job doesn't really require me to get my
code to compile across a lot of platforms and compilers. It's guys like PJ
who bear the brunt of these problems.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top