Jump to content

ASCII vs ISO


Stremik

Recommended Posts

As I was going through one of the C++ tutorials on the web, I've

learned that there are two ways of using #include directive.

Depending on what standard you use.

If it's ASCII than it whould be put this way,

#include <filename.h>

and if it's ISO than it would look like this.

#include <filename>

The author of the tutorial was particularly fond of the second one,

(ISO),but did not explain why it should be preferred over the ASCII.

Can anyone please shed some light on the subject? I'm confused!

I don't know squat about them standards in the first place!

Thank you!

Vladimir

Link to comment
Share on other sites

Hi vladimir,

ASCII is a standard for character sets (the codes that represent keys on the keyboard, for example). The acronym itself stands for "American Standard Code for Information Interchange", but has nothing to do with standardizing the C++ language. And ISO is the "International Organization for Standardization" and they (together with a whole bunch of other organizations, including ANSI and IEC I believe) are definitely more involved in producing a standard for the C++ language.

Long story short, standard C++ headers don't (shouldn't) carry the ".h" extension. So when you #include them, you use <filename> instead of <filename.h>. Additionally, all symbols from these headers are supposed to be defined in the std namespace (so you need to use fully qualified names, or the using keyword to access them).

Hope that helps,

Cheers!

Link to comment
Share on other sites

Note that on some (many?) systems, the old library headers are still included so it gets confusing easily.

eg. For old iostreams:

#include <iostream.h>

For new iostreams:

#include <iostream>

They're just different files that include slightly different things.

Link to comment
Share on other sites

Note that on some (many?) systems, the old library headers are still included so it gets confusing easily.

13279[/snapback]

Yes; and as if that weren't enough confusion, some of the early "standard" headers have since become deprecated and changed names!

Most notably:

What used to be <strstream.h> (from early SGI STL I think) later became <strstream> in the early ISO/IEC standard, but was deprecated, so some up-to-date standard-comforming implementations (gcc) don't include either, and opt for the current standard, which is <sstream> (and the class ostringstream instead of the old ostrstream)

Can you say "Annoying!" ? :mad:

Cheers!

Link to comment
Share on other sites

O boy! As if there was not enough confusion for me allready!

I'm drowning in C++!

So, what and how should I <#include> (I have BCC5.5 installed on

my system under Windows2000 Pro)?

Vladimir

13288[/snapback]

BCC?... that's Borland, right?

Well; I'm afraid the last time I used a borland compiler was around 1985 or thereabouts. So all I can safely say is "check your compiler documentation".

But if it is even somewhat standard compliant (which I'd imagine it is if version 5.5 is recent), then you should be safe to "do the right thing" and include any of the standard headers without the ".h" extension (and also assume that the implementation of the classes themselves are standard). So you would:

#include <filename>

I think the main differences between compilers nowadays are mostly related to how they handle templates, template-template parameters, static member initialization, partial template specialization, and the more esoteric generic-programming aspects of the language. I doubt any of them should choke with #include <standard_header> anymore. But Edward please correct me if I'm wrong.

Cheers!

Link to comment
Share on other sites

Say. Which compiler would you recommend to use? A free one.

13290[/snapback]

I'm using GCC (g++) 3.3.3, and I'm really happy with it. It is free, but then I'm on Linux (SuSE 9.1). I *think* you can use it under winoze through Cygwin, or MinGW, or some such, but I've never had to try that so I'm not sure.

Link to comment
Share on other sites

Actually... I thought that was an old topic... I've never gotten it to work, tho... In the end, it was just much easier to deal with it with G++ under mingw (for W32, that is).

I have no idea why the "Studio" edition has "Optimized Compiler" while the standard edition doesn't... MS is MS, I guess... :(

Link to comment
Share on other sites

I don't understand why the heck do they still call it "Visual"!!!

You have to do everything at the command prompt.

Anyway! I've installed "Visual C++ Toolkit" and Bloodshed's "Dev-C++"

I'll see which one of them works better for me.

Thanks for your help guys!

Vladimir

Link to comment
Share on other sites

I thought the HDK requires the M$ .NET compilers for Windows machines and that the GNU compilers wouldn't work or be supported ...

13332[/snapback]

Hey Mark,

Well; it would just have to be able to link against the Houdini libraries, and play nice with the loader. If I go by what I read in the MinGW and Cigwin websites, then it would *seem* that using the gnu tools would be possible (provided all the proper compile/link flags are given in terms of threads, exceptions, GL, rtti, etc). Has anyone tried it? Or is it simply guaranteed not to work no matter what? Edward?

I guess I should start looking into this given the imminent arrival of the HDK for us little people! :P

Cheers!

Link to comment
Share on other sites

Yeaha! MOre documentation. goodie goodie.  :balloon:  :oneeyedsmiley02:

13335[/snapback]

Don't mean to burst your bubble there, but I heard (from a very reliable source) that this free HDK is meant to be community supported. IOW; I wouldn't hold my breath for heaps of documentation.

On the other hand; I don't care if it comes with little or no documentation... as long as it comes!! I'll be grinning like an idiot either way :)

Oh; and we could always bug Jason, Edward, and any other HDK veterans in this forum for the bits that we can't figure out on our own! :lol:

I suspect the wiki will see some HDK-related action in the near future!

Cheers!

Link to comment
Share on other sites

Don't mean to burst your bubble there

Hhahaah. FUnny, considering I was using that bubble icon. :) Might have been hilarious if there's the bubble burst icon. :lol:

Actually, I was thinking more along the line of user-written documentation, like in the odwiki, rather than SESI's docs. THe odwiki is a really awesome reposits of Houdini related tips and tricks. Kudos to Marc and Jason. :thumbsup:

Link to comment
Share on other sites

Guest xionmark
Well; it would just have to be able to link against the Houdini libraries, and play nice with the loader. If I go by what I read in the MinGW and Cigwin websites, then  it would *seem* that using the gnu tools would be possible (provided all the proper compile/link flags are given in terms of threads, exceptions, GL, rtti, etc). Has anyone tried it? Or is it simply guaranteed not to work no matter what? Edward?

Hi Mario!

I seem to remember this discussion, that is about linking to Houdini lib's, but I thought there was also an issue with SESI not supporting anything other than the "blessed" compiler. For example, the transsition from Visual C++ 6.0 to the new .NET stuff ... VC6 isn't supposed to be used anymore because of changes to the streams and templates. :(

--Mark

Link to comment
Share on other sites

Guest xionmark

FYI: From the HDK dev list:

On Thu, Oct 23, 2003 at 11:34:26AM -0700, Mark Story wrote:

>> Hi all,

>>

>> Is the required compiler for WIN32 HDK builds now the 2003 .NET suite?

The "official" compiler is the 2003 .NET suite.

>> I've had some problems with using MSVC 6.0 with the HDK v6.1, but the

>> docs make no mention of the possible change ... SESI support mentioned

>> they're using .NET, I think, but not sure.

There has been some confusion on this issue. We have moved

our internal build over to .NET. There are some template related

compiler bugs with MSVC 6.0 which were resulting in numerous problems

in COPs.

The main reason why you have noticed a change is that MSVC

2003 does not support the old style streams. The 6.1 build of Houdini

thus changed its stream library as of 6.1.149.

This means we are internally building two versions - the MCVS

6.0 with the old stream library and the MSVC .NET with the new stream

library. The makeheaders was left to split between the two based on

the compiler version, which is incorrect, as it should split based on

the compiler version of the BUILD machine.

To work around this, edit makeheaders to change the >= 1300s

into >= 100s. Then re-run makeheaders and you should be able to

compile SOP_Star.

Future releases of 6.1 will have the makeheaders set up to

work with the .NET build out of the box.

-- - Jeff Lait

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...