Sign in to follow this  

I need some things cleared up...

This topic is 3873 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm pretty new to C++ and I'm having trouble understanding exactly how it works... I know quite a few programming languages; Java, C#, VB and a bunch of web scripting languages and server-sides. Now I'm finding the concept of using external APIs confusing somehow... Can someone please answer the following questions: - What languages are APIs like the Windows API programmed in? Or is it just direct machine code... If the APIs are just machine-code, then how is it that we can access them in C++ using a C-like interface? Are APIs like Windows or OpenGL totally separate from C++? Am I totally off track? Please clear up whatever you can regarding external APIs. - Now, Seeing as I know C#, I noticed that it's a lot like Java and unlike C++... Is it because C# has an interface for popular APIs and is that the big difference between it and C++? - When making a game in C++ and OpenGL, how to you create the 3D models? Which programs do you use? Also, relating back to question one, I heard that Open-GL was procedural in nature... Wouldn't that mean that it's impossible to make a C++ OpenGL applications... Because it would pretty much be just C if it's procedural. Is there any other question which I have not asked which you think I might need answers to in the future? Please explain. Thanks a bunch!

Share this post


Link to post
Share on other sites
Quote:
Original post by Flashthinker
I'm pretty new to C++ and I'm having trouble understanding exactly how it works... I know quite a few programming languages; Java, C#, VB and a bunch of web scripting languages and server-sides. Now I'm finding the concept of using external APIs confusing somehow...


The first and most important thing you need to learn is that you don't know as much as you think you know. For example, the fact that you don't seem to think Java/C#/VB/etc involve using external APIs tells me quite a lot about your level of experience with those technologies.

Quote:

- What languages are APIs like the Windows API programmed in?
The bulk of the API is written in C, and can be consumed by C and C++ code (as it happens the API is valid C++ even though it wasn't originally written as such). There are ways of working with it from other languages, though; plus, some parts of the API are exposed via COM, which can be consumed by a large number of languages.

Quote:
Are APIs like Windows or OpenGL totally separate from C++?
Yes.

Quote:
- Now, Seeing as I know C#, I noticed that it's a lot like Java and unlike C++... Is it because C# has an interface for popular APIs and is that the big difference between it and C++?
My guess is that by "interface for popular APIs" you're talking about the .NET Framework, yes? The .NET framework is not 'part' of the C# language, the two just come packaged together. You can write C# code that doesn't make use of it.

Quote:
- When making a game in C++ and OpenGL, how to you create the 3D models? Which programs do you use?
Personally, I use Wings3D and Blender; others use things like 3D Studio Max, Maya, or SoftImage XSI.

Quote:
Also, relating back to question one, I heard that Open-GL was procedural in nature... Wouldn't that mean that it's impossible to make a C++ OpenGL applications... Because it would pretty much be just C if it's procedural.
The OpenGL API on Win32 is written in C, but can be consumed by both C and C++ applications just like the rest of the Win32 API.

And if you think that the API being procedural means you can't use it in C++, then you need to revise your definitions. Specifically, you need to consider that C++ is not an object-oriented language; it's a hybrid language that allows a number of paradigms, including both object-oriented programming and procedural programming.

Share this post


Link to post
Share on other sites
API - Application Programming Interface

It's an abstract term, and as such isn't defined by code. It is a contract between user and some logic. API provides definition of one system interacting with other.

Historically, many APIs are language and platform dependant. Reason for this is that they provide simplest and least-overhead method for connecting various separate systems. Alternative would obviously be some external communication method, such as sockets or pipes.

API can be defined regardless of language ( CORBA IDLs ).

Java, C++, C# and VB are languages. Each provides a set of language libraries, which are generally considered to be part of language. While Standard C++ library has an API, it's considered part of language.

Majority of languages provide ability to create self-sufficient libraries or modules with certain functionality. In order for others to use them, they provide a language-specific or platform neutral API (if accessed remotely).

Windows provides a huge set of interfaces that allow a large number of applications to interact with various parts of operating system at different levels. These go from lowest level kernel access to highest level abstractions such as ActiveX, or even higher, like VB for Applications.

API in this case serves as boundary between user and implementation (which is proprietary and not accessible to user).

OpenGL, for example, is an API. It defines a contract of how to render graphics (among other things). This API is provided for various platforms and various languages. In addition, various chipset developers provide their own implementations. But the user only knows about API, regardless of language or platform.

Windows API isn't programmed in anything. Windows API defines how Windows OS can be accessed from most MS supported languages (VB, C#, C++).

What the Windows OS itself is written in is mostly irrelevant. Probably C and C++.

This is the key advantage of providing an API for a piece of software. Users can develop their own software without knowing anything about your implementation or even the language used. They are given an interface which defines how to do it.

Whether something is procedural, OO, functional, ... is completely irrelevant here.

Share this post


Link to post
Share on other sites
Quote:

The first and most important thing you need to learn is that you don't know as much as you think you know. For example, the fact that you don't seem to think Java/C#/VB/etc involve using external APIs tells me quite a lot about your level of experience with those technologies.


Really? How would I go about invoking a native system API in Java? I knew that you can use external APIs as in not-built-in system APIs, or maybe I didn't word my question properly, what I meant by *external* APIs was "Native APIs" like those C++ invokes; Win32 and OpenGL, I noticed that in Java, I can only use Java-specific APIs like Java3D and JOGL, can I use true OpenGL though?

About your attack on my over-confidence, I never said that I was a "PRO" I just said that I "know" them as in; I am quite familiar with their structure and API. I do not know many advanced features. I only know what I need to know at this stage. I will look into what you mentioned though (about external APIs, not about my level of confidence :p)
I didn't mean to boast btw, I just thought it might give people common grounds on which to base their answers.

Quote:

My guess is that by "interface for popular APIs" you're talking about the .NET Framework, yes? The .NET framework is not 'part' of the C# language, the two just come packaged together. You can write C# code that doesn't make use of it.


No, I was talking about the functions of APIs like the Windows API (Win32 is it?), I'm under the impression that the .NET framework is just a "reformating" layer that groups calls to popular system APIs in a more OOP manner.
Also, I have to admit, I don't fully understand how the .NET framework works, I'm going to do some research, but if you'd like to share your thoughts, I'd appreciate it.

Quote:

And if you think that the API being procedural means you can't use it in C++, then you need to revise your definitions. Specifically, you need to consider that C++ is not an object-oriented language; it's a hybrid language that allows a number of paradigms, including both object-oriented programming and procedural programming.


Ok, thanks a lot :)
Things are much clearer now.

[Edited by - Flashthinker on May 8, 2007 8:11:24 AM]

Share this post


Link to post
Share on other sites
Quote:
Original post by Antheus
...

Windows API isn't programmed in anything. Windows API defines how Windows OS can be accessed from most MS supported languages (VB, C#, C++).


Oh, so do "system APIs" like Windows API's actual implementation define various Interfaces which are language-specific. So far, I'm thinking that the actual implementation (which as you said, is hidden) of the API is responsible for setting up ways by which it can comunicate with programming languages... And these "Ways" are what we, as programmers call the API. This would make a lot of sense, but am I on the right track?

I appreciate the amount of detail you used in your descriptions.

Thanks.

Share this post


Link to post
Share on other sites
Quote:

I am quite familiar with their structure and API. I do not know many advanced features. I only know what I need to know at this stage.


Quote:

The first and most important thing you need to learn is that you don't know as much as you think you know.


It's not a slight or an attack. Just a cautionary suggestion that people without a broad knowledge of the subject are ill-equipped to judge their own relative knowledge of the subject. There was a link semi-recently which described this a lot more eloquently than I, but alas I cannot find it.

Share this post


Link to post
Share on other sites
Quote:
Original post by Flashthinker
Quote:
Original post by Antheus
...

Windows API isn't programmed in anything. Windows API defines how Windows OS can be accessed from most MS supported languages (VB, C#, C++).


Oh, so do "system APIs" like Windows API's actual implementation define various Interfaces which are language-specific. So far, I'm thinking that the actual implementation (which as you said, is hidden) of the API is responsible for setting up ways by which it can comunicate with programming languages... And these "Ways" are what we, as programmers call the API. This would make a lot of sense, but am I on the right track?


Today, if you want to draw something on screen with all the bells and whistles, you have DX and OpenGL, along with SDL and all that.

But before then, clearing screen buffer was different. On FooGraphics2000 card, clearing a screen was done with interrupt 56. On FooGraphics1200 card, it was interrupt 34, unless the user was in EGA compatibility mode, then it was 56 with parameter 0x023a.

But, BarVision required user to clear the memory by filling 0xA000 with zeroes, then calling interrupt 12. If user was in text mode, then they needed to fill 0xB000 with zeroes.

See the problem...

When VESA was introduced, it was sort of an API for graphics cards. It standardized common functionality. And while it was still obscure (interrupts, addressess, etc.), it was at least to a degree consistent.

Under VESA, clearing screen buffer as assigned interrupt 15. Calling that would work on all cards consistently.
Note: these numbers and the rest are made up.

But, whether you used assembler, Pascal, C++ or anything else, the only thing that was different, was how you issued an interrupt. The interrupt was always '15', but each language required different call to perform that. Function and logic remain the same, syntax differs.

Today, with processing constraints no longer being a problem, most functionality can be provided through a semantic high-level API. Types, calling conventions, transformations, they are all provided under the hood as needed.

Flexibility of an API however depends on its purpose. A C++ library doesn't need to be callable anything but C++. Microsoft Word API however needs to be language independant, and possibly even cross-platform, either via RPC or other means.

Quote:
Really? How would I go about invoking a native system API in Java?


You generally don't want to do that, but if you insist and abandon portability, look up JNI.

It's ugly, it's horribly ugly, it's incredibly ugly, but it works. You create piece of native code (C++ or C, it's been a while), compile it with your native compiler, then call that code from Java as it were a regular class or function.

It also provides means of passing Java types to and from native system.

But it's ugly. It's worse than ugly, it's fugly.

Share this post


Link to post
Share on other sites
Quote:
Original post by Telastyn
It's not a slight or an attack. Just a cautionary suggestion that people without a broad knowledge of the subject are ill-equipped to judge their own relative knowledge of the subject. There was a link semi-recently which described this a lot more eloquently than I, but alas I cannot find it.



It is an attack, but it was delivered with good intentions.
I'd like to think that I'm pretty humble, but I understand that some people do over-estimate their capability and I would appreciate being critisized if it were the case for me. But in my wording, I understand how it could seem like I was boasting, I was in fact just saying that, I "know" the languages in a casual manner, not in a "I'm the pro and James Gosling's knowledge in Java is like a pixel on a 22" LCD when compared to mine" kind of way.

Share this post


Link to post
Share on other sites
Quote:
Original post by Flashthinker
Really? How would I go about invoking a native system API in Java? I knew that you can use external APIs as in not-built-in system APIs, or maybe I didn't word my question properly, what I meant by *external* APIs was "Native APIs" like those C++ invokes; Win32 and OpenGL, I noticed that in Java, I can only use Java-specific APIs like Java3D and JOGL, can I use true OpenGL though?

If you use Jogl (or, my preference, LWJGL, then you're pretty much using OpenGL directly. All they really do is provide a bit of glue code between the C interface and the Java language. 99% of all OpenGL documentation still applies, and the bits that don't are usually trivial to convert.

Lots of APIs just provide a C interface as it's a good low-level common denominator. Then higher level languages just have to write a bit of glue to present the C functions as Java/Python/Whatever functions.

Share this post


Link to post
Share on other sites
Superpig is the highest rated member on these boards... He didn't get there by making remarks to put people down or attack them; he got there by being helpful and spend his time writing elaborate replies to peoples questions, as is the case here.

Try putting this 'attack' behind you and focus on the replies that you got that were on topic, since people are trying to help you here.

Share this post


Link to post
Share on other sites
Quote:
Original post by CipherCraft
Superpig is the highest rated member on these boards... He didn't get there by making remarks to put people down or attack them; he got there by being helpful and spend his time writing elaborate replies to peoples questions, as is the case here.

Try putting this 'attack' behind you and focus on the replies that you got that were on topic, since people are trying to help you here.


I did long ago. And it was an attack no matter how you look at it. Anything which has the potential to dammage my confidence is an "attack" towards me... No matter the intentions, it is what it is.
I am a new user after all, I don't know anyone around here so I'm quick to judge. At first, it sounded like he was trying to degrade me by showcasing his technical superiority on the matter. It was all a misunderstanding. I did thank him for his help didn't I? Geez, why such a fuss?

Share this post


Link to post
Share on other sites
Quote:
Original post by Flashthinker
Really? How would I go about invoking a native system API in Java? I knew that you can use external APIs as in not-built-in system APIs, or maybe I didn't word my question properly, what I meant by *external* APIs was "Native APIs" like those C++ invokes; Win32 and OpenGL, I noticed that in Java, I can only use Java-specific APIs like Java3D and JOGL, can I use true OpenGL though?
As noted, JNI is where to go. C# has Platform Invoke (or interoperability through C++/CLI), VBScript has COM support (and your COM objects can be written in C++), etc. At the end of the day, it's all machine code, and the processor doesn't care which source language was used to generate that machine code. As long as you've got the tools to splice things together, you're golden.

Quote:
About your attack on my over-confidence, I never said that I was a "PRO" I just said that I "know" them as in; I am quite familiar with their structure and API. I do not know many advanced features. I only know what I need to know at this stage. I will look into what you mentioned though (about external APIs, not about my level of confidence :p)
I didn't mean to boast btw, I just thought it might give people common grounds on which to base their answers.
As noted, it wasn't meant as an attack per se. I've been programming for 16 years and I still don't "know" C++ (as evidenced by my performance on Washu's periodic quizzes). Problem is that to "know" a technology isn't a terribly descriptive thing - do you "know" it as in you've heard of it, do you "know" it as in you've been writing code in it for X years, do you "know" it as in you invented it, etc etc... I can see that this is something you understand.

Quote:

No, I was talking about the functions of APIs like the Windows API (Win32 is it?), I'm under the impression that the .NET framework is just a "reformating" layer that groups calls to popular system APIs in a more OOP manner.
Also, I have to admit, I don't fully understand how the .NET framework works, I'm going to do some research, but if you'd like to share your thoughts, I'd appreciate it.
It's more than just a wrapper - there's lots of stuff in there that doesn't have operating system components underlying it (for example, the database access components). In truth the .NET Framework is just one massive collection of libraries, some of which are self-contained and some of which are connected to external technologies like the Win32 API.

Also, re: Win32 - that's the nickname given to the 32-bit C API for Windows programming. Things like pointers are expected to be 32 bits in size. Under the 64-bit operating systems there are doubtless some functions that expect pointers to be 64 bits in size - these functions could be considered to be the 'Win64 API.'

At the end of the day, it comes down to this:

You've got a technology (like Windows). It does a whole bunch of things.

In order to have other technologies (like your application) interact with it, it needs to provide an interface for application programmers to work with it (an API).

Application programmers may be writing their applications in a great variety of languages and in a great variety of different build environments. Some people use Unicode. Some people are building 32-bit code while others are building 64-bit code. Etcetera.

You have to expose interface(s) to all the application programmers you want to allow to use your system. This does mean that your technology may have multiple APIs - for example, game engine The Nebula Device has APIs for C++, Python, Lua, and TCL (to say the least). Sometimes these APIs will exist side-by-side; other times you build one API on top of another (e.g. your Python API converts Python calls into C++ calls that then go through the C++ API).

Windows in particular exposes a second C interface at the other end of things, called the Device Driver Interface - as you may guess, it's an interface for device driver programmers to use to work with Windows, as opposed to applications programmers. Both the Win32 API and the 32-bit DDI (Win32 DDI) are exposing the same underlying technology - Windows - but in ways that make them more suitable to their respective users. The DDI gives you much lower-level data but (usually) in smaller chunks, while the API is higher-level and more oriented towards the tasks that Windows programs want to get done (for example, creating and destroying a window).

Quote:

And if you think that the API being procedural means you can't use it in C++, then you need to revise your definitions. Specifically, you need to consider that C++ is not an object-oriented language; it's a hybrid language that allows a number of paradigms, including both object-oriented programming and procedural programming.


Ok, thanks a lot :)
Things are much clearer now.[/quote]I should note as well that you can write object-oriented programs in C. Object-orientation, procedural, functional... these things are all just programming styles. When we talk about an "object-oriented language," what we mean is a language that is 'friendly' to that particular style - has built-in support for the constructs, etc, such that using that style with that language may be easier than elsewhere.

OcaML is generally referred to as a functional language, but here's some OcaML code:

for i = 1 to 10 do
eprintf "%i\n" i
done

Looks procedural, no? Reads like a sequence of commands to be executed. The point is that while you can write procedural-style code in a functional language like OcaML, you'll find that you can't take advantage of many of the language features if you do so. Things like let statements don't really lend themselves to a procedural style.

Share this post


Link to post
Share on other sites
Quote:
Original post by superpig
Windows in particular exposes a second C interface at the other end of things, called the Device Driver Interface - as you may guess, it's an interface for device driver programmers to use to work with Windows, as opposed to applications programmers. Both the Win32 API and the 32-bit DDI (Win32 DDI) are exposing the same underlying technology - Windows - but in ways that make them more suitable to their respective users. The DDI gives you much lower-level data but (usually) in smaller chunks, while the API is higher-level and more oriented towards the tasks that Windows programs want to get done (for example, creating and destroying a window).


Wow, I'd love to learn how to use that DDI someday... Would it also allow me to program to external devices like a robot of some kind (assuming that I had the proper hardware)? If so, that'd be awesome!

Also, I'm really surprised at how helpful people are in this forum, I've learned more *theory* (as in; what's happening behind the scenes) about C,C++ and APIs in the two days that I've been here than I have in the past few months! I never thought I'd ever understand computers this well, but obviously, taking into account what you said about your own experience, I still have a LOT more to learn!

Share this post


Link to post
Share on other sites
It depends on the robot interface. Something like the serial port can be controlled directly in normal application code and if that's how you communicate with the robot you don't need a driver. You may interface with the robot through USB which probably will require writing a driver. Or maybe the communication is wireless so you make your own PCI card which can transmit wireless signals which Will require writing a driver.

The driver specifies the communication between the hardware and the higher level software. It depens on the hardware what kind of software you'll end up needing. If you want a pretty cheap way to start messing around with hardware you can look into programming a microcontroller (which is probably what would control a robot). There are kits out there for developers that you might look into someday. When I worked with microcontrollers I used HC12 and PIC18F based processors (in the later case the PICDEM FS USB demo board from Microchip, in the former case I forget exactly what we used). Something like the picdem would be a great way to start mucking around with hardware which is a lot of fun and relatively cheap(less than a new desktop computer, more than post card depending on how into it you get)

Share this post


Link to post
Share on other sites
Quote:
Original post by nobodynews
Something like the serial port can be controlled directly in normal application code and if that's how you communicate with the robot you don't need a driver.
Indeed - for some hardware, such as printer or serial ports, there's a sort of datapath between the API and the DDI - so you can feed your data to the port through the API and a standard port driver that sits between the DDI and the hardware.

Quote:
You may interface with the robot through USB which probably will require writing a driver.
Actually, USB might not - XP provides an API for reading data from USB devices (the Raw Input API), though at a glance I can't find how to write data to a USB device. On other OSes - Mac OS X, for example - I know that there is a general-purpose API for reading and writing USB devices.

Share this post


Link to post
Share on other sites
Quote:
Original post by superpig
Actually, USB might not - XP provides an API for reading data from USB devices (the Raw Input API), though at a glance I can't find how to write data to a USB device. On other OSes - Mac OS X, for example - I know that there is a general-purpose API for reading and writing USB devices.


Well how about that? Thanks for the info. Maybe I'll try fudging around with an old web-cam whose driver never worked on XP.

Share this post


Link to post
Share on other sites

This topic is 3873 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this