Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

For basic C++ questions.

Status
Not open for further replies.

pghsteelers

Technical User
Apr 21, 2006
121
US
I have a number of questions that I was hoping I could through up here, mainly all are clarification request on understanding some principles or syntax clarifications, as opposed to created a new thread for each one:

1)Can someone explain the arguments to the function main in for a CLR program?

int main(array<System::String ^> ^args)

I have an idea as but would like to know if someone could break down what that argument in the main function is? A CLR array?

2)The following is a line that I understand is creating an CLR array named "saying" containing a wide string with the value that specified in between the "". However, the following explanation after the source line is what is confusing me and hoped someone could explain it better.

Code:
String^ saying = L"I used to think I was indecisive but now I'm not so sure";

Note that the type of the string literal is const wchar_t*, not type String. The way the String class has been defined makes it possible for such a literal to be used to create an object of type String.

3)Using the Array::BinarySearch() function - the problem I am having is understanding how the complement bitwise of either the first index position that is greater than the object you are searching for, or the 'Length' property of the array if no element is found to be greater - tells exactly where the position is that the item you are searching would fall or where it is, if found? - What is the "complementing bitwise"? I understand the different bitwise operators and how they work, but how is it actually working out in the Aaray::BinarySearch() function?

Thanks in advance for any and all help understanding some of these a little better.
 
Just so you know, when I mentioned using VC++ 2005 in the other thread, I meant using the C++ compiler and not any of the CLR features. I would focus on one language at a time, and only use the IDE for regular C++ (e.g. Win32 Console Application- Empty Project) for now.
 
Exactly. I believe that CLR crap is still just a Microsoft standard, not part of the real C++ standard. Learn C++ first, and then you can move into .NET if you want.
 
I was curious if there was really any other "standard" to be applied to programming in CLR vs. native other than possibly a quicker compilation for native programming, or quicker programming with CLR and its attributes and extras..ect?

Is there a another standard at which one can apply to determine whether it a program should be written in CLR or native ? And is there an issue with possible compiler/computers not being able to run CLR writen programs?
 
Only machines that have the .NET runtime installed can run CLR programs. So it will run on Windows as long as the user installs the .NET runtime. As for other OS's like UNIX... I'm not sure if Microsoft has ported the .NET runtime to them yet (or if they will).

.NET does offer you a huge number of built in classes that come with your compiler, so in that respect, it might speed up your development time by not reinventing the wheel.
 
Right, making a fool of myself:
question 1: yes, it's a CLR array of Strings containing all the parameters passed to the program in the command line used to start its execution.
question 2: the string literal is a different thing to the variable whose type is String ('saying'); the literal is the stuff between inverted commas, which can't have a type String because otherwise you couldn't work with an L"string" in standard C++.

But I do get puzzled by C++'s strong typing of literals whose type should be obvious, and sudden lack of typing elsewhere. Pedantic question along those lines: I'm told I shouldn't initialise a pointer to NULL because NULL is a type-less alias for 0, and everything in C++ with a name should also have a type. Therefore I should initiate a pointer to 0, not NULL. But if my system has addresses that consist of more than a single number (e.g. old 16-bit addressing), it really makes no sense to assign zero to a pointer (which part of the pointer becomes zero?). It would be much better to state that there will be a null-pointer literal called NULL, but its format and nature may vary between compilers according to their target system's memory structure. And somewhere in the universe there is a machine which actually has a valid address at zero.

So why can't we have NULL?

 
I've heard that argument going back & forth, but I really think they're just trying to find something pointless to complain about. I always initialize my pointers to NULL, not 0. It's much easier for me to see the word NULL when I'm scrolling through my code than 0. Plus NULL is basically just this:
Code:
#define NULL (void*)0

As for the typing part of the argument, I'm wondering why they don't go as far as suggesting to use something like:
Code:
int*  pInt = static_cast<int*>(0);
char* pStr = static_cast<char*>(0);
...
;-)
 
Interesting... Do you have any idea how nullptr will be defined? I mean how will it be different from 0 or (void*)0? I'm kind of also wondering why they're changing the name to nullptr instead of just using NULL, which would save people from having to do a Find & Replace on a lot of old code...
 
Cool thanks!
We should not define the standard library macro NULL to nullptr. It is tempting to do so, but it would
break code, even though in many cases that would be code that deserved to be broken.
I'm kind of wondering how many people actually do some of the stupid things with NULL that are listed in that document? :)
 
Crumbs, I had no idea I was opening such a can of worms. It was just something that leapt out at me as illogical while reading a C++ textbook.

Thanks for the superb links, uolj. I like the idea of nullptr very much; it's a good name, recogniseable at a glance.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top