OSDev.org

"Everyday code" isn't OS kernel code. Actually, "everyday code" usually isn't even valid C89.

Combuster wrote:And in what percentage of everyday code would you expect people to use intptr_t?

I still expect 100%, either directly or indirectly (typedef). If I see you using an int for a pointer in a professional environment, you're going to get a number of discussions with me.

Candy wrote:

Combuster wrote:And in what percentage of everyday code would you expect people to use intptr_t?

I still expect 100%, either directly or indirectly (typedef).

So after every day of programming you have used at least one intptr? No wonder there's a shortage in IT professionals...

If I see you using an int for a pointer in a professional environment, you're going to get a number of discussions with me.

When i do 'professional' coding, there are no explicit pointers (Java )

Combuster wrote: And in what percentage of everyday code would you expect people to use intptr_t?

I would imagine if you loaded a file image int memory (I am talking about normal user space Linux and Windows programming) so that..


FileHeader *fhdr;
FileSection *fsec;
void *buffer = malloc(fstat.st_size);
read(fd, buffer, fstat.st_size);
fhdr = (FileHeader*)buffer;
fsec = (FileSection*)(((uintptr_t)buffer) + fhdr->mapSectionFileOffset);


At some point in time you would need to understand pointers. I mean you could most likely just change that example above to perform a read(..) for the header, then seek to the section header and perform another read(..), but it seems things could be much more efficient to just load the entire file image and do a little pointer math.

I hung out in a C/C++ channel on IRC one time..... They made me so mad. I would post some code.. it would turn into a feeding frenzy for portability and non-standard coding lectures, and yes I was the one all alone trying to defend what I did. It was almost like I had cold blooded killed a man in broad day light...I thought they were nuts. And on top of that they had this zealot infantry team shooting balls of melted code and you idiot mines with the idle goblin crew posting, "hehe, haha".

They were much much harsher than me or anyone I have seen on this forum. Here you are likely to get a answer but in a low post exposure medium such as that you get ignored and you feel much more stupid thatn at least having someone take the time to post something, even if it is negative overall, that does provide some sort of feedback.

They most likely would have told neon to STF[?] with out the sugar coating --(pause)-- when we actually took the time to answer (We did, yes, just read back from the original thread post). And if he would have told those guys in that medium that he 'knew the language' after they gave a answer and if they gave a answer it would have been a bomb explosion of a extremely large pack of wild animals bouncing on the keyboards and slobbering on the screens with some sort of strange mating ritual.

I never heard of intptr_t. I do, however, define my own types in
larger programs where portability is a concern. However, I typedef
types for size (ie, int32_t, word_t, byte_t, float64_t, etc)

I believe int32_t will be an added type in the next revision of the
standard of C++. I could be wrong though.

@Kevin McGuire: You make a valid point. Any time I had to create
a file codec, pointers are necessary. And in some forums/IRC channels,
I could imagine someone telling me to "STF*" through my statement.
I dont coinsider this harsh--just ignorance.

I help members on several different forums on programming, and am
quite good at it Im still getting used to the "OS dev" mindset though

iteresting... personally i would stick to pointers instead of using uintptr_t.

declare buffer ar char * instead of void *; i personally think uintptr should be used as minimal as possible. (not sure this is good english)

neon wrote:I never heard of intptr_t. I do, however, define my own types in
larger programs where portability is a concern. However, I typedef
types for size (ie, int32_t, word_t, byte_t, float64_t, etc)

I believe int32_t will be an added type in the next revision of the
standard of C++. I could be wrong though.

Bzzzzzzzzzzzt.

(That's the electroshocker doling out punishment.)

At first I thought Tyler's reaction was a bit harsh, but you actually don't know the language.

Kindly check out the header <stdint.h> to which I have been referring earlier, which is part of the language you claim to "know", for eight years now, and which - aside from intptr_t - contains standard-compliant typedef's for int8_t, int16_t, int32_t, int64_t, intmax_t, uintmax_t...

<rant>

As I said, "everyday code" is usually not even compliant C89, because too many programmers are too bloody lazy to actually get their arses up and stay on top of their respective skills.

But oh, no, "I do know the language" (I just don't use most of it) is so convenient an excuse.

</rant>


(Yes I know <stdint.h> is C99 only, and thus not (yet) part of C++, but neon claimed he knows C and C++.)

Kindly check out the header <stdint.h> to which I have been referring earlier, which is part of the language you claim to "know", for eight years now

Um...

-I said 4 years, not 8;
-I dont even have stdint in my MSVC++ 2005 compilier IDE;
-...Nor my GCC compilier;
-I personally never seen anyone use stdint

According to Wikipedia, it is part of C99. I know why GCC might not
have it, but Why Would MSVC++ 2005 exclude it?

Lastly: Just because one doesnt know a specific file (as they have never
used it) doesnt mean they dont know how to use the library. Your
argument is akin to saying "If you dont know this specific include
file, you dont know the Win32 API"

...Even though they could use Win32 API just fine.

Hence, your argument is invalid.

I would also like to add how you are comparing a language with a library.

I stated I know C++ very well. I never stated that I know all of
the standard library; and I dont know anyone who does.
Professional developer, or not.

neon wrote:I would also like to add how you are comparing a language with a library.

I stated I know C++ very well. I never stated that I know all of
the standard library; and I dont know anyone who does.
Professional developer, or not.

Yeah i totally agree!!!!! It is like how people tell me i don't know French just because i don't know the vocabulary at all. I am always like, shut up i so know the language because i know the basic structure of the sentence!

Also... sarcasm...

Yeah i totally agree!!!!! It is like how people tell me i don't know French just because i don't know the vocabulary at all. I am always like, shut up i so know the language because i know the basic structure of the sentence!

Um, no its not. Here you are comparing the basics of a language
(like C/C++ data types, pointers/refrences, structs, functions, etc)
to advanced concepts (polymorphism, OOP/OOD, mabey UML,
multiple inheritance, abstract classes, et al..)

In my case, I was comparing a language with a library. (ie; C++
with cstdlib, or C++ with Win32 API)

One could write very good programs without needing any library;
which is why they arnt required.

If one is to place the standard library as part of the language,
then I could easily say:

Almost no one knows C++; as they do not know alot or some of the standard library.

^This is the argument you are applying. If you want to continue this
argument, then I can only assume Most members do not know C++
-- Including members on this board. Coinsidering I dont know all
of the standrad library, this includes me.

Enough of this pointless argument.

If you do not know your language inside out then you really should not be Developing an Operating System. I can assure you that every serious developer and poster here knows the core of their library inside out. This is the reason most people specify platform as well as language (i.e. you have Win32 C++ Developers)

If you do not use the Standard C/C++ library then i can understand your argument... otherwise i stick by it. You do not know C/C++ unless you know the library you use it with. In OSdev you must know the platform inside out (in this case not only the library you have ported but the functionality exported by the hardware)

One could write very good programs without needing any library;
which is why they arnt required.

Assuming of course you are not just trying to be cocky and claim that "technically" the BIOS is not a library and Hardware functionality doesn't class as library, despite the fact you comission it to do the work... then i would love to see that program.

knows the core of their library inside out.

What do you define as "Core"?

I know alot of the standard library, but admit I dont know all of it.
And, as stated, I help other developers from several forums,
and have yet to see one developer that knows it all.

Reguarding the standard library, I only know routines and classes
for which I use (Which includes 30+ header files)

Assuming of course you are not just trying to be cocky and claim that "technically" the BIOS is not a library and Hardware functionality doesn't class as library, despite the fact you comission it to do the work... then i would love to see that program.

Um... ...operating system development? o.0

Assuming you write your own bootloader. (Of course, you should
port a standard library, but you still need to build it)

neon wrote:I know alot of the standard library, but admit I dont know all of it.

And i don't know every word in the english language. Point pretty much made.