The long subject says it all. I have to sort a database and with my current level of knowledge it would be easier to write an algorithm in C++ than it would be to find some way to do it with Access itself. Basically I have a databse with 1200 records each with 30 fields, and I need to do pattern-matching between the fields to match each record up with another. I think I can do it in C++....but I would need a way to even access the Access database from within the program. Does such a beast exist?
WAYYY off topic: C++ question - are there class files that will let me access ODBC DBs from within a C++ Console app?
- Thread starter beer
- Start date
Maybe you want to post this also in software, applications and programming if you want to get an answer. Good luck.
If you are using VC++ you can use MFC and the database wizard to access ODBC. It sucks but it will get you the connection.
[edit]
...or you can simply use Java and the ODBC/JDBC bridge and be up in no time.
[edit]
...or you can simply use Java and the ODBC/JDBC bridge and be up in no time.
The problem is, I'm a first year AP Comp Sci I student and right now we're just using console C++ (aka DOS Box). It's not Win32...
FYI, the IDE I'm using is the Metrowerks CodeWarrior....
FYI, the IDE I'm using is the Metrowerks CodeWarrior....
Suggesting Java as a solution to a problem? Hmm... 
Elemental, goto www.microsoft.com/data and download the MDAC SDK. This will give you all the appropriate libraries (static libraries/headers, COM components, etc.) you'll need to either a) Interface w/ it in a COM environment (VB/A et. al), or build your console app. There are plenty of ODBC API samples in the SDK that should get you up and running in no time.
HTH
Elemental, goto www.microsoft.com/data and download the MDAC SDK. This will give you all the appropriate libraries (static libraries/headers, COM components, etc.) you'll need to either a) Interface w/ it in a COM environment (VB/A et. al), or build your console app. There are plenty of ODBC API samples in the SDK that should get you up and running in no time.
HTH
I can probably code his solution in 10 lines of Java code as opposed to 100+ lines of low level ODBC or COM code.
dwell: I can code his solution in about the same amount of lines in VB, Perl (win32), PowerBuilder, ad nauseum.
Length of code isn't indicative of a good solution.
Length of code isn't indicative of a good solution.
Having worked in Visual Basic for far too long -- writing COM objects in VB is not fun -- as well as having work with Java and C++ and C and Scheme and I can't keep track of how many other languages...
How the heck can you say VB, for instance, is a hack?
I'll agree that Java is object-oriented out of the box, but VB was, far as I'm concerned, designed to throw wrappers around existing objects. Look at how big the market is for VB OCXs... admittedly it's started to slow down, but there is still huge demand. The COM objects everyone loves right now developed from early versions of VB's controls.
Furthermore, from what I know, one of the primary uses of VB has been to design database front ends. After all, when the majority of your work is going to be offload to a database object (via ADO, MDAC, ODBC, etc), there's no reason why you shouldn't use VB for a quick and dirty, and even production level, front end.
I'm not saying Java isn't an extremely useful language, and can in most cases certainly exceed the power of VB, for instance, saying the VB is a hack is certainly going overboard, particularly in the area of database interfacing. My first DB access work was done in VB, and took less than two minutes to set up and access.
In any case, this is away from the initial question -- the questioner wanted a C++ solution, and the MDAC suggestion was probably the best of the bunch, provided he's allowed to use it, and the Windows platform is okay.
Andrew
How the heck can you say VB, for instance, is a hack?
I'll agree that Java is object-oriented out of the box, but VB was, far as I'm concerned, designed to throw wrappers around existing objects. Look at how big the market is for VB OCXs... admittedly it's started to slow down, but there is still huge demand. The COM objects everyone loves right now developed from early versions of VB's controls.
Furthermore, from what I know, one of the primary uses of VB has been to design database front ends. After all, when the majority of your work is going to be offload to a database object (via ADO, MDAC, ODBC, etc), there's no reason why you shouldn't use VB for a quick and dirty, and even production level, front end.
I'm not saying Java isn't an extremely useful language, and can in most cases certainly exceed the power of VB, for instance, saying the VB is a hack is certainly going overboard, particularly in the area of database interfacing. My first DB access work was done in VB, and took less than two minutes to set up and access.
In any case, this is away from the initial question -- the questioner wanted a C++ solution, and the MDAC suggestion was probably the best of the bunch, provided he's allowed to use it, and the Windows platform is okay.
Andrew
I knew you were going to say that.
Many would say the same thing about Java. What about VB constitutes it as a "hack" ? The fact that it encapsulates the win32 API w/ the VB runtime? Java encapsulates plenty for the programmer, so that argument is moot. Unless you're writing in straight ASM/C/C++ (I know, technically there's always an abstraction layer) straight against the Win32 API, you've got some automagic in the background.
Nothing is wrong with Java, as long it's being used because it fits the scope of the solution, and not simply because it's a) the only language one knows or b) because one is a language bigot. Not saying you are, it's just what I've come across at times.
Many would say the same thing about Java. What about VB constitutes it as a "hack" ? The fact that it encapsulates the win32 API w/ the VB runtime? Java encapsulates plenty for the programmer, so that argument is moot. Unless you're writing in straight ASM/C/C++ (I know, technically there's always an abstraction layer) straight against the Win32 API, you've got some automagic in the background.
Nothing is wrong with Java, as long it's being used because it fits the scope of the solution, and not simply because it's a) the only language one knows or b) because one is a language bigot. Not saying you are, it's just what I've come across at times.
Weird, I posted then 2 messages showed up before mine.
dwell: You're kidding, yah? What does melding any language into a RAD environment have to do w/ a hack? So, you consider the VC++ dialog editor a hack when you're using MFC to build an interface instead of spending hours upon hours setting up the handlers for the message queue, build your rc files, etc.? Perhaps instead of building solid apartment-threaded COM objects in VB, I should spend 4x the time building a COM component in C++ by hand?
Since you spout off anti-VB sentiments everytime it's mentioned, I can only assume you've done nothing more than regurgitate the dogmatism that you've probably experienced in an environments where bigots are a plenty? Have you ever worked with VB? Can you build me an MTS/COM+ COM component in Java that can beat the performance of a well-designed VB MTS/COM+ component? Riiiiight.
dwell: You're kidding, yah? What does melding any language into a RAD environment have to do w/ a hack? So, you consider the VC++ dialog editor a hack when you're using MFC to build an interface instead of spending hours upon hours setting up the handlers for the message queue, build your rc files, etc.? Perhaps instead of building solid apartment-threaded COM objects in VB, I should spend 4x the time building a COM component in C++ by hand?
Since you spout off anti-VB sentiments everytime it's mentioned, I can only assume you've done nothing more than regurgitate the dogmatism that you've probably experienced in an environments where bigots are a plenty? Have you ever worked with VB? Can you build me an MTS/COM+ COM component in Java that can beat the performance of a well-designed VB MTS/COM+ component? Riiiiight.
Frost: I worked with VB with versions 3 and 4. To be blunt, it sucked. At this point in time, I could care less about COM, DCOM, MTS, DNA, MFC, .NET and all the rest of the Microsoft technologies de jour.
I used to be a Microsoft Windows developer. I have used VC++, MFC, Win32, COM extensively. I became utterly frustrated with the technology and have since moved on.
Yes, I use Java now, keep in mind that is not all I use. I still develop under Windows. I would not consider myself an ABM (Anything But Microsoft) bigot. However, as a software developer of close to 10 years I have to say that most Microsoft development solutions suck.
Sure, they make pretty IDEs and crafty wizards. Aside from that, I have seen 12th graders put together better frameworks and APIs than Microsoft.
I used to be a Microsoft Windows developer. I have used VC++, MFC, Win32, COM extensively. I became utterly frustrated with the technology and have since moved on.
Yes, I use Java now, keep in mind that is not all I use. I still develop under Windows. I would not consider myself an ABM (Anything But Microsoft) bigot. However, as a software developer of close to 10 years I have to say that most Microsoft development solutions suck.
Sure, they make pretty IDEs and crafty wizards. Aside from that, I have seen 12th graders put together better frameworks and APIs than Microsoft.
I'm sorry, but I just don't buy that. The TPC has quite frequently shown the benchmarks of a Microsoft MTS/COM+ solution vs. straight ASP vs. a Sun solution (JSP, Java, whatever), and it bitch slaps Sun to the point where it's almost childish to even compare.
Honestly though, if you think COM/MTS/COM+ is potentially a framework that could be better designed by some 12th graders, then you don't know any of the above. I'd like to see a better API than the Win32 API by any other competitive product. When I first started working w/ the Win32 API in C, my initial thoughts were, "WTF?" It seems everything sucks to the ignorant.
Honestly though, if you think COM/MTS/COM+ is potentially a framework that could be better designed by some 12th graders, then you don't know any of the above. I'd like to see a better API than the Win32 API by any other competitive product. When I first started working w/ the Win32 API in C, my initial thoughts were, "WTF?" It seems everything sucks to the ignorant.
Frost: Benchmarks are always skewed. I can show you benchmarks that prove the contrary. It's like IIS vs. Apache, NT vs Linux. Both sides can spin benchmarks however they see fit.
If you think the Win32 API is so great I don't know where you learned to code. Obviously API consistency and clarity are not tops on your priority list.
You call me a bigot but I can't help label you a Microsoft shill.
If you think the Win32 API is so great I don't know where you learned to code. Obviously API consistency and clarity are not tops on your priority list.
You call me a bigot but I can't help label you a Microsoft shill.
dwell: API consistency? Do you have _any_ WIN32 API experience, or are you just talking out of your arse?
Perhaps to the uninformed, the API is not clear, but nor is Java/C/C++ to a developer of a "hacked" language.
Are you going to try to put an argument about the consistency of APIs that exists for *nix platforms now?
I'm sorry that MSDN couldn't elucidate the WIN32 API enough for you, but perhaps that's why you're working in Java?
Perhaps to the uninformed, the API is not clear, but nor is Java/C/C++ to a developer of a "hacked" language.
Are you going to try to put an argument about the consistency of APIs that exists for *nix platforms now?
I'm sorry that MSDN couldn't elucidate the WIN32 API enough for you, but perhaps that's why you're working in Java?
<round 5>
Frost: What part of consistency do you not understand? In Win32 one window method may be prefixed with Win (WinMain), in another it's Window (WindowProc) but in a macro elsewhere it's just plain WND (WNDCLASS).
Win32 is an example of how 15 years and 1,000 authors lead to an unsorted mess. Add to it all the STUPID_MACRO_NAMES and the lpszHungarianNotation everywhere and you have a jumbled pile of garbage. Maybe stuff like that flew in 1989, but this is the 21st century.
As for *nix, I have more experience with Windows than that platform. Based on my limited exposure to some of the Linux APIs, I have to say that they suck as well. Whoever designed GTK+ most have been smoking crack at the keyboard.
The beauty of Java is that I really don't need something like MSDN to understand what is going on. If I want to get some data I use the consistent get method, set->setXXXX, etc. You should know about it, it seems Microsoft stole quite a lot of Java's good practices and kludged them into C#.
Frost: What part of consistency do you not understand? In Win32 one window method may be prefixed with Win (WinMain), in another it's Window (WindowProc) but in a macro elsewhere it's just plain WND (WNDCLASS).
Win32 is an example of how 15 years and 1,000 authors lead to an unsorted mess. Add to it all the STUPID_MACRO_NAMES and the lpszHungarianNotation everywhere and you have a jumbled pile of garbage. Maybe stuff like that flew in 1989, but this is the 21st century.
As for *nix, I have more experience with Windows than that platform. Based on my limited exposure to some of the Linux APIs, I have to say that they suck as well. Whoever designed GTK+ most have been smoking crack at the keyboard.
The beauty of Java is that I really don't need something like MSDN to understand what is going on. If I want to get some data I use the consistent get method, set->setXXXX, etc. You should know about it, it seems Microsoft stole quite a lot of Java's good practices and kludged them into C#.
dwell:
WindowProc is a callback function, and they're loquacious with the names in the documentation so they get the point across. Name if foo() if you want. Since WNDCLASS is a structure, it's pretty consistent with regards to other types in the API (HWND, etc.).
Hungarian Notation is a moot argument, as some are adamantly against it, and some aren't. Personally, that's probably the only thing that really frustrated me initially about Win32 API and COM development, but you eventually get used to it. The stupid macro names are for a reason. They provide an abstraction from the underlying type that's essential in the COM standard. Sometimes they go overboard, but it's still better than having to trudge through code replacing data types.
I wholeheartedy agree with you on GTK+. I was actually quite excited when I first started playing with GTK+, as I was looking for the ethereal platform to work with at the time. Didn't find it there.
I make no claims to be a Java pundit, as my development with Java is limited. It's concise enough, however, that I can usually understand what's going on w/o having my eyes glaze over. So, I agree w/ you there. I much prefer the syntax of a C'esque language vs. any Basic derivative, but sometimes I don't have the choice.
Yes, C# admittedly borrowed from Java, C++, etc.. This is not a surprise, as I think it's safe to say that the majority of languages borrowed from others. As they say, "If you're going to reinvent the wheel, make sure it's a better wheel." While C# may not fit the niche of Java, it has improved on many aspects for the niche it serves.
WindowProc is a callback function, and they're loquacious with the names in the documentation so they get the point across. Name if foo() if you want. Since WNDCLASS is a structure, it's pretty consistent with regards to other types in the API (HWND, etc.).
Hungarian Notation is a moot argument, as some are adamantly against it, and some aren't. Personally, that's probably the only thing that really frustrated me initially about Win32 API and COM development, but you eventually get used to it. The stupid macro names are for a reason. They provide an abstraction from the underlying type that's essential in the COM standard. Sometimes they go overboard, but it's still better than having to trudge through code replacing data types.
I wholeheartedy agree with you on GTK+. I was actually quite excited when I first started playing with GTK+, as I was looking for the ethereal platform to work with at the time. Didn't find it there.
I make no claims to be a Java pundit, as my development with Java is limited. It's concise enough, however, that I can usually understand what's going on w/o having my eyes glaze over. So, I agree w/ you there. I much prefer the syntax of a C'esque language vs. any Basic derivative, but sometimes I don't have the choice.
Yes, C# admittedly borrowed from Java, C++, etc.. This is not a surprise, as I think it's safe to say that the majority of languages borrowed from others. As they say, "If you're going to reinvent the wheel, make sure it's a better wheel." While C# may not fit the niche of Java, it has improved on many aspects for the niche it serves.
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 25K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes + WCL Discussion Threads
- Started by Tigerick
- Replies: 23K
-
Discussion Intel current and future Lakes & Rapids thread- Started by TheF34RChannel
- Replies: 23K
-
-
Facebook
Twitter