Is it standard and practical to use long long types?

[Ioannis Vranos]

Correct. There are clever ones and dumb ones, nice ones and not
so nice ones, rude experts and kind imbeciles; there are people
feeling the necessity to practise self discipline in human
interaction, and there's Dan Pop. ;-)

If it were not for his expertise, he probably would've been
killfiled by everybody around. However, the art of successfully
communicating with Dan includes the ability to listen to what he
has to say, while blissfully ignoring the way he presents it.
His exaggerations can actually be very amusing, if you avoid to
make the mistake of taking it personally.

If I were to complain about anyone in amusenet, I'd rather object
to people like the resident quote forging troll in c.l.c, or the
ineffable nilgewater dispenser in c.p. But anyway, that's just me.

Perhaps someone will write a Dan Pop to rest human speech translator, it
can't be that difficult. One simple app where one will input Dan Pop
sentences, and read the output. Like something that will replace "B*****IT"
with "Yes, but".

Well if i have some free time this weekend i will make a GUI Dan Pop
translator in .NET and make it available for download somewhere.






Ioannis Vranos

 

[jacob navia]

In <[email protected]> "jacob navia"

2. main() is defined as returning int, but it doesn't return anything at
all. Methinks a warning is badly needed.

I HAD this warning, but in a discussion in this SAME GROUP in which YOU
also participated I was pointed to the C99 standard that defines main as
returning zero when no result is specified. I worked a day to implement
and test this "feature".

This is just bad faith Dan.

This discussion was a few weeks ago!

 

[jacob navia]

Error test.c: 3 redeclaration of 'fileno' previously declared at
h:\lcc\include

\stdio.h 149

fileno returns the integer value (the file number) of a FILE
structure.

If I had a team of people working in lcc-win32 (as gcc has)
and a huge budget (as MSVC has) I would fix this and other
warnings, looking at each function to see which is declared
in the standard and which not.

jacob

 

[Irrwahn Grausewitz]

Perhaps someone will write a Dan Pop to rest human speech translator, it
can't be that difficult. One simple app where one will input Dan Pop
sentences, and read the output. Like something that will replace "B*****IT"
with "Yes, but".

Well if i have some free time this weekend i will make a GUI Dan Pop
translator in .NET and make it available for download somewhere.

Nice, I'll port it to a standard C command line version, if I get
your permission. BTW, some more things that need replacement,
from the top of my head:

engage your brain
think harder
patent idiot
resident idiot
idiotic statement
...

Regards

 

[James Kuyper]

lcc-win32 implements most of C99. ....
I am not as orthodox as you would like,
and I dare to believe that C is not a dead
language and can be improved.

Dan's claim was that lcc-win32 doesn't come close to having a fully
C99-conformant mode. I know nothing about lcc-win32, so I have no idea
whether or not he's right. However, it's not a claim that justifies
your response. A fully conforming mode is not incompatible with a live
language; the live language could be the lcc default, with the
fully-conforming mode being an option. Furthermore, even the fully
conforming mode can have a great many non-standard features, as long
as those features are provided as extensions that can only be invoked
by code that has undefined behaviour as far as the standard is
concerned.

 

[Ioannis Vranos]

Nice, I'll port it to a standard C command line version, if I get
your permission.

I 'll make also a command-line tgnu/linux port since i don't know X-Windows
programming (QT mainly). The software will be available under the GNU
license and i am thinking it will have an update option to download
dictionary updates from the net.


BTW, some more things that need replacement,

from the top of my head:

engage your brain
think harder
patent idiot
resident idiot
idiotic statement

)) Think better, "", Be more careful, Why don't you understand?, careless
statement are possible translations.


Also the program will be two way, it will be able to convert normal language
to DP language so as to help DP thinking and reply faster.






Regards,

Ioannis Vranos

 

[Sam Dennis]

If I had a team of people working in lcc-win32 and a huge budget I
would fix this and other warnings, looking at each function to see
which is declared in the standard and which not.

I'm sorry, but that is just pathetic. There's a summary in the standard
(at least, in C99; I'd be surprised if it was absent from C90) of what's
declared in every standard header.

Neither a large team nor budget is required to put #ifdefs around all of
the identifiers not in that list. It should not even take much of your,
evidently precious, time.

(#ifdef _POSIX_C_SOURCE seems like a good choice for this feature.)

 

[Thomas Stegen]

Ioannis Vranos wrote:

[snip]

Yeah, because the conversation you two are engaging in
is of course not rude.

 

[Irrwahn Grausewitz]

I 'll make also a command-line tgnu/linux port since i don't know X-Windows
programming (QT mainly). The software will be available under the GNU
license and i am thinking it will have an update option to download
dictionary updates from the net.

I wonder if one could implement a Bayesian filter and scan the
archives. )

)) Think better, "", Be more careful, Why don't you understand?, careless
statement are possible translations.

Actually, the Popism "resident idiot", when used in c.l.c, usually
refers to poor chap Marc McIntyre, but simple replacement might lead
to mildly tautological statements like "Marc McIntyre is our Marc
McIntyre."; "respected fellow poster" might fit better, then.

Also the program will be two way, it will be able to convert normal language
to DP language so as to help DP thinking and reply faster.

Oh, unlimited possibilities... :^]

Regards

 

[Ioannis Vranos]

I HAD this warning, but in a discussion in this SAME GROUP in which YOU
also participated I was pointed to the C99 standard that defines main as
returning zero when no result is specified. I worked a day to implement
and test this "feature".

If you write a compiler (and not only) you must have the document of the
standard. Don't you have the standard?



In C99 if you do not return a value from main(), it is the same as if you
wrote return 0; . But if your compilers cis in ANSI C90 compliance mode, and
not C99 then you have to issue a warning.






Ioannis Vranos

 

[Ioannis Vranos]

fileno returns the integer value (the file number) of a FILE
structure.

If I had a team of people working in lcc-win32 (as gcc has)
and a huge budget (as MSVC has) I would fix this and other
warnings, looking at each function to see which is declared
in the standard and which not.

The global variables you are using in the library must not have an ordinary
name. The standard tells more on this. Please tell if you have the standard.
For C99 it is ISO/IEC 9899:1999 .






Ioannis Vranos

 

[Ioannis Vranos]

Actually, the Popism "resident idiot", when used in c.l.c, usually
refers to poor chap Marc McIntyre, but simple replacement might lead
to mildly tautological statements like "Marc McIntyre is our Marc
McIntyre."; "respected fellow poster" might fit better, then.

I dropped tonight some lines of code. The dictionary file goes like this:

// DP Dictionary file
//
// Syntax: DP term=Human term

engage your brain=think
idiot=careless
idiotic=erroneus
bullshit=wrong


-----------


And the main engine so far (at the very beginning):


Available under the GNU GPL

// The main engine of DP written in ISO C++ 98

#include <fstream>
#include <string>
#include <cctype>

class DictionaryFileException
{
};

class dictionaryFile
{
std::ifstream dicFile;
std::string dicFileName;

public:
dictionaryFile(const std::string &filePath) throw (DictionaryFileException)
{
dicFileName=filePath;
dicFile.open(filePath.c_str());

if(dicFile.fail())
throw DictionaryFileException();

FileValidation();
}

void FileValidation() throw (DictionaryFileException)
{
using namespace std;

char input[2];

do
{
dicFile.get(input,2);

if(isspace(input[0]) or (input[0]=='\\' and input[1]=='\\'))
continue;

else if(!isalpha(input[0]) and !isdigit(input[0]))
throw DictionaryFileException();

}while(!dicFile.eof());
}
};






Ioannis Vranos

 

[CBFalconer]

.... snip ...

If you write a compiler (and not only) you must have the document
of the standard. Don't you have the standard?

In C99 if you do not return a value from main(), it is the same as
if you wrote return 0; . But if your compilers cis in ANSI C90
compliance mode, and not C99 then you have to issue a warning.

No you don't. It's a QOI matter, not a standards matter.

FUPs set.

 

[Irrwahn Grausewitz]

I dropped tonight some lines of code. The dictionary file goes like this:

// DP Dictionary file
//
// Syntax: DP term=Human term

And the main engine so far (at the very beginning):

Available under the GNU GPL

// The main engine of DP written in ISO C++ 98

<snip>

Sigh. Seems I have to learn C++ _seriously_ in the end, then;
somehow managed to get away without doing it, up until now. ;-)

Regards

 

[Dan Pop]

I HAD this warning, but in a discussion in this SAME GROUP in which YOU
also participated I was pointed to the C99 standard that defines main as

Do you remember MY contribution to that discussion? I was strongly
arguing that your compiler was doing the RIGHT thing. You chose to ignore
my advice and now you're making ME responsible for that?!?

Dan

 

[Dan Pop]

fileno returns the integer value (the file number) of a FILE structure.

I know. I also know that it is not a standard C library feature.
I didn't put this particular identifier in my test program by pure
chance ;-)

If I had a team of people working in lcc-win32 (as gcc has)
and a huge budget (as MSVC has) I would fix this and other
warnings, looking at each function to see which is declared
in the standard and which not.

This is, of course, bullshit: identifying the nonstandard identifiers
in a standard header is a piece of cake for any serious implementor
(use grep, when in doubt) and grouping them together under the
protection of an #ifdef is even easier. Note that this is only needed
for identifiers from the program name space, you can leave the ones
in the implementation name space unprotected and no one will have
any business to complain.

Make your project open source and I'm sure you'll find people willing to
help improving it.

Dan

 

[jacob navia]

----- Original Message -----
From: "Dan Pop" <[email protected]>
Newsgroups: comp.lang.c,comp.lang.c++
Sent: Friday, April 16, 2004 1:59 PM
Subject: Re: Is it standard and practical to use long long types?

In <[email protected]> "jacob navia"

Do you remember MY contribution to that discussion? I was strongly
arguing that your compiler was doing the RIGHT thing. You chose to ignore
my advice and now you're making ME responsible for that?!?

Wait Dan, I saw that sentence in the standard, and I wrote
in this group that you were right.

But I have to follow the standard.

As you, I do *not* agree with this stuff for main, but I should
do as specified anyway.

I have tried to keep all extensions compatible with the
standard and make C99 the base of the language lcc-win32
supports.

jacob

 

[Keith Thompson]

I've removed comp.lang.c++ from the newsgroups header.

From: "Dan Pop" <[email protected]> [...]

Do you remember MY contribution to that discussion? I was strongly
arguing that your compiler was doing the RIGHT thing. You chose to ignore
my advice and now you're making ME responsible for that?!?

Wait Dan, I saw that sentence in the standard, and I wrote
in this group that you were right.

But I have to follow the standard.

But the standard doesn't say you can't issue a warning.

The standard requires diagnostics for syntax errors and constraint
violations, but an implementation is absolutely free to produce as
many additional diagnostics as it likes. (Most warning messages, as
oppposed to error messages, are like this.) If the main function
falls off the end without executing a return statement, a
C99-conforming compiler must generate code that causes it to return a
successful status, but the compiler is free to issue a warning.

As a quality-of-implementation issue, I'd suggest changing the wording
for the special case of main(), making it clear that it's allowed by
C99 but is nevertheless a bad idea. (That's a matter of opinion, of
course, but it's your compiler, and you can have it express whatever
opinion you like.)

 

[jacob navia]

----- Original Message -----
From: "Keith Thompson" <[email protected]>
Newsgroups: comp.lang.c
Sent: Saturday, April 17, 2004 1:59 AM
Subject: Re: Is it standard and practical to use long long types?

I've removed comp.lang.c++ from the newsgroups header.

From: "Dan Pop" <[email protected]> [...]

Do you remember MY contribution to that discussion? I was strongly
arguing that your compiler was doing the RIGHT thing. You chose to ignore
my advice and now you're making ME responsible for that?!?

Wait Dan, I saw that sentence in the standard, and I wrote
in this group that you were right.

But I have to follow the standard.

But the standard doesn't say you can't issue a warning.

The thread was about a user complaining that this warning
was contradicting the standard. I get flamed anyway

How can I issue a warning about something that is
*explicitely* allowed? I thought about that but it looks
weird isn't it? If the standard explicitely allows this
stuff a warning is misplaced. A better way would be
to change the standard, what looks like a minor change to
C99.

 

[Ioannis Vranos]

The thread was about a user complaining that this warning
was contradicting the standard. I get flamed anyway

Since you *have* the standard why don't you check what it is written? I do
not consider myself capable of writing a compiler yet, but why don't you
begin implementing the standard from the first page towards the last?

How can I issue a warning about something that is
*explicitely* allowed?

If you aim for C99 compliance you *must not* issue a warning about not
returning a value from main(). Dan Pop was saying that since you have not
implemented all C99 features (and supposedly you have implemented all the
C90 ones), you must work in C90 till you finish your C99 work.







Ioannis Vranos