- use existing dll - 6 Updates
- "Linus Torvalds Was (Sorta) Wrong About C++" - 16 Updates
- Cgi and c++ - 1 Update
- "Linus Torvalds Was (Sorta) Wrong About C++" - 2 Updates
| "astro.del.cielo" <vedi@lasignature.com>: Mar 13 10:25PM +0100 Hi all I'm very newbe so be patient :P I have a "simple" question I have to use a existing dll to comand my ipcam The dll is ZSightLib.dll and it contain ZSP_SetImageColor that i need to use I need to call it So how can i do? thanks -- a.d.c. |
| Vir Campestris <vir.campestris@invalid.invalid>: Mar 13 09:32PM On 13/03/2015 21:25, astro.del.cielo wrote: > thanks > -- > a.d.c. They should have supplied you with instructions on how to call the interface. Ideally a .h file - but something else that tells you what parameters and what return codes are expected would do. You've not given enough information. Imagine you want to call fopen - you need to know the name of the file, the mode to open it in, and the type of the return data. That's all documented - but this DLL isn't on the net. I looked. Andy |
| Paavo Helde <myfirstname@osa.pri.ee>: Mar 13 04:45PM -0500 "astro.del.cielo" <vedi@lasignature.com> wrote in news:mdvkks$cgo$1 > use > I need to call it > So how can i do? Normally the vendor of the library would give you at least a SDK package with header files and .lib files to link to, but as you have stated you have only the dll file this seems to be not the case. If so, you will probably need to use LoadLibrary() and GetProcAddress(). And then you have to know the exact parameter types and calling conventions for your function, write them down in a function pointer typedef, cast the pointer you got from GetProcAddress() to that type and call it! Profit! hth Paavo |
| "astro.del.cielo" <vedi@lasignature.com>: Mar 13 10:49PM +0100 Il 13/03/2015 22:32, Vir Campestris ha scritto: > the mode to open it in, and the type of the return data. That's all > documented - but this DLL isn't on the net. I looked. > Andy You can find it here: http://surveillance.zmodo.com/support-software Zviewer for PC => Zviewer2.0.0.9_Setup.exe Installing program you can find ZSightLib.dll I don't have any .h file I only inspect ZSightLib.dll with dllexp.exe (NIRSOFT) I don't know if there is a way to interface with it.. Thanks ;) -- a.d.c. |
| "astro.del.cielo" <vedi@lasignature.com>: Mar 13 10:54PM +0100 Il 13/03/2015 22:45, Paavo Helde ha scritto: > And then you have to know the exact parameter types and calling conventions > for your function, write them down in a function pointer typedef, cast the > pointer you got from GetProcAddress() to that type and call it! Profit! I'm not a programmer (just on school) So my level is poor I only use ZSP_SetImageColor so i can make a script to invoke color with my ipcam. I think the solution is to make a small program that invoke ZSP_SetImageColor thanks -- a.d.c. |
| Christopher Pisz <nospam@notanaddress.com>: Mar 13 04:58PM -0500 On 3/13/2015 4:49 PM, astro.del.cielo wrote: > Thanks ;) > -- > a.d.c. Looks to me that ZViewer is an application and the dll you speak of is used by that application. There is nothing on that site, that I saw, to indicate that they want to allow you to program anything using their dll as a dependency. What information led you to the conclusion? Or are you just mistaken in thinking you can link with any old dll? If that is the case. No you can't. You can only program against dlls that the author created with that intention...easily anyway. -- I have chosen to troll filter/ignore all subthreads containing the words: "Rick C. Hodgins", "Flibble", and "Islam" So, I won't be able to see or respond to any such messages --- |
| Johannes Bauer <dfnsonfsduifb@gmx.de>: Mar 13 03:11PM +0100 On 11.03.2015 20:35, Paavo Helde wrote: > In the extreme case where each byte must be conserved, I agree that with C- > style arrays and lots of work one can win some bytes. But as C is a proper > subset of C++, It isn't. > the same code can then be used as C++ code and still have > better type-checking and other goodies. Setup of NVIC configuration for embedded systems: Designated initializers is the only practical solution. C++ doesn't have those, sadly. Cheers, Johannes -- >> Wo hattest Du das Beben nochmal GENAU vorhergesagt? > Zumindest nicht öffentlich! Ah, der neueste und bis heute genialste Streich unsere großen Kosmologen: Die Geheim-Vorhersage. - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org> |
| Martijn Lievaart <m@rtij.nl.invlalid>: Mar 13 03:37PM +0100 On Fri, 13 Mar 2015 10:03:35 +0100, David Brown wrote: > steps of programming. But while I'd not recommend anyone to bother > learning VB, since there are better alternatives, if the choice was only > C++ or VB for first language, then VB is a better choice.) Do note that VB.net is a half decent language, but VB up till version 6 or most forms of VBA are so buggy and badly documented, I would advice to learn C++ instead. M4 |
| Martijn Lievaart <m@rtij.nl.invlalid>: Mar 13 03:39PM +0100 On Thu, 12 Mar 2015 14:34:29 -0500, Christopher Pisz wrote: >> The vast overwhelming majority of shitty C++ code I've seen is written >> by people who keep writing C code and calling it C++. > I second that emotion. I don't. I've seen tons of shitty code by C++ programmers who should read Meyers to get the basics right. M4 |
| Martijn Lievaart <m@rtij.nl.invlalid>: Mar 13 03:39PM +0100 On Thu, 12 Mar 2015 16:34:35 +0000, JiiPee wrote: >> unless I know I cannot afford it. >> M4 > In an embedded system? What is unclear about "unless I know I cannot afford it"? M4 |
| David Brown <david.brown@hesbynett.no>: Mar 13 04:03PM +0100 On 13/03/15 15:37, Martijn Lievaart wrote: > Do note that VB.net is a half decent language, but VB up till version 6 > or most forms of VBA are so buggy and badly documented, I would advice to > learn C++ instead. My experience with VB is almost all with VB3 (it was the only serious RAD tool for Win3.1, until Delphi came out). Yes, it was buggy and badly documented - and on the couple of occasions when I tried to talk to MS technical support, I knew a great deal more than they did. But for simple projects, it is relatively easy to get the idea of programming without being faced with the complications of compilers and build processes, or the relatively complex syntax of C++. A "Hello, world" project is easier in VB than C++. However, it is even easier in Python. |
| Johannes Bauer <dfnsonfsduifb@gmx.de>: Mar 13 04:19PM +0100 On 13.03.2015 15:39, Martijn Lievaart wrote: >> I second that emotion. > I don't. I've seen tons of shitty code by C++ programmers who should read > Meyers to get the basics right. Yes, and it's a cop-out to just claim these were not "real" C++ programmers, and were ACTUALLY just coding C. Because "real" C++ programmers do everything right, of course. The problem is not that C++ is a bad language, it's a fantastic one. The problem rather is that it is MUCH more complicated than C is, yet somehow creates the illusion that it's just "C with goodies". It is very easy to create C++ code that is impossible to refactor because it's design is so broken. Since C does not offer a lot of room to play with, it's much harder (but sure enough still happens on a daily basis). That said, both languages are nothing for beginners. I can only shake my head when people suggest C++ as a first language. Cheers, Johannes -- >> Wo hattest Du das Beben nochmal GENAU vorhergesagt? > Zumindest nicht öffentlich! Ah, der neueste und bis heute genialste Streich unsere großen Kosmologen: Die Geheim-Vorhersage. - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org> |
| David Brown <david.brown@hesbynett.no>: Mar 13 04:30PM +0100 On 13/03/15 16:00, Stefan Ram wrote: > have reached the point where they can use the language > productively in their lives, while some students in my C++ > courses might never reach that point. Have you considered Python rather than VB, with LibreOffice rather than MS Office? I haven't actually use Python with LO - I've never felt the need - but I am curious to your opinion as someone who actually teaches beginners' programming classes. |
| BGB <cr88192@hotmail.com>: Mar 13 10:40AM -0500 On 3/13/2015 4:57 AM, Martijn van Buul wrote: > or i7, with about 16GB of memory) - yet it is still considered an embedded > system, and much of the issues I'm facing are very similar to the problems seen > on, say, a phone. I think cost mostly... like, a faster processor is more expensive, and may require multiple chips (such as a processor, maybe an external bridge, external RAM chips, ...). OTOH, a smaller processor is often all on a single chip, or may be available with more options for packaging (say, if you want DIP rather than QFP, ...). though, with the higher-end processors, it may be cheaper to buy premade boards with the processors and RAM and Flash and similar already on them (may have solder-points or pin-headers for interconnect, or some use edge-connectors and plug into a slot on the parent-board, ...). >> allocation (may be problematic, unavailable, or introduce delays), > It's neither. It's surprisingly predictable. Whether you want do do > dynamic memory on all of your RT tasks is something altogether different. there is a delay involved in allocating memory, so you don't want to do it while running in-loop. on lower-end hardware, there may be no memory allocator (not enough RAM to make having one be worthwhile, and you allocate the RAM by using variables). >> may exist, so sanely sized global arrays can keep waste low. > .. and it can explode in your face, because suddenly you face yourself with > having to allocate for mutually exclusive worst-case scenario's. usually, the scenarios are known in advance, and the compiler will complain if you used too much memory (or the ROM would be too big). typically this makes the most sense for statically-known small-N cases. for big-N or unpredictable cases, dynamic allocation may be better, or the resource requirements may be too big to use on the hardware in the first place. > the state machine from whatever it is controlling, (hopefully) leading to > better code quality. Whether that results in an unacceptable performance > penalty is largely the result of implementation details. could be. a lot of state-machine stuff IME is done either with switches, or by fun with function-pointers (stick in the desired callback for the given state). a switch-based state may cost a byte or maybe a few bits. depending on the HW, a function pointer may cost 16 or 32 bits, but may be faster than the switch. > there. > I've done OO on microcontrollers (which, admittedly, would have been > considered premium workstation classs hardware only a few years ago) I think it depends on what class of hardware one is talking about. ARM Cotext-A or Atom based, yes, probably... MSP430 or megaAVR or tinyAVR or similar, not so much... Z80 can be pretty nice though (at least vs an AVR), but generally these are also used with external RAM. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Mar 13 05:03PM On 13/03/2015 10:04, Johannes Bauer wrote: > I claim to be able to write code that ACTUALLY WORKS in my scenario > where any single reference to STL functionality blows the code so out of > proportion that it becomes LITTERALLY unusable on constrained hardware. If you can't get std::vector to work on embedded hardware then either: 1) you've got a shitty C++ compiler or 2) the actual overhead is C++ exceptions (but see 1) or 3) you don't know how to use C++ properly wrt contrained hardware. /Flibble |
| Louis Krupp <lkrupp@nospam.pssw.com.invalid>: Mar 13 11:33AM -0600 On Fri, 13 Mar 2015 15:11:20 +0100, Johannes Bauer >initializers is the only practical solution. C++ doesn't have those, sadly. >Cheers, >Johannes Interesting. I hadn't heard of designated initializers, so I looked them up, and I found this: http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=550 Louis |
| scott@slp53.sl.home (Scott Lurndal): Mar 13 05:47PM >like, a faster processor is more expensive, and may require multiple >chips (such as a processor, maybe an external bridge, external RAM >chips, ...). The newer server processors are moving towards SoC. Cavium's ThunderX, for example - 48x 64-bit arm cores, 2x 40Gb ethernet w/ SR-IOV (or 8x 10Gb et alia), 16 SATA controllers, 16 lanes of PCIe3.0, various accelerators, four memory controllers - all on one (rather big) chip. Intel is also producing server SoC's (not just Atom). |
| Ian Collins <ian-news@hotmail.com>: Mar 14 08:10AM +1300 Scott Lurndal wrote: > I think most of us would prefer that you keep your rants to > yourself. Here as well. Stick to discussion of C++ and > leave your foolish hatred of C programmers at home. I don't see hated, just one who has been scarred for life by the havoc some C programmers who claim to know C++ (or mathematicians who claim to know C) can cause. I have been through the recovery programme so my trauma is greatly reduced. But it is still there luring in the background. -- Ian Collins |
| Ian Collins <ian-news@hotmail.com>: Mar 14 08:15AM +1300 Stefan Ram wrote: > C++ > #include <iostream> > int main() { ::std::cout << "Hello, World" << "\n"; } Maybe the superfluous colons put them off :) -- Ian Collins |
| Ian Collins <ian-news@hotmail.com>: Mar 14 08:20AM +1300 Johannes Bauer wrote: >> better type-checking and other goodies. > Setup of NVIC configuration for embedded systems: Designated > initializers is the only practical solution. C++ doesn't have those, sadly. There I agree. A pointless omission from C++11. My embedded C++ projects usually end up with one C TU to perform static initialisation. -- Ian Collins |
| scott@slp53.sl.home (Scott Lurndal): Mar 13 07:28PM >them up, and I found this: >http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=550 >Louis For what its worth, g++ supports designated initializers as a GNU extension. |
| scott@slp53.sl.home (Scott Lurndal): Mar 13 07:29PM >some C programmers who claim to know C++ (or mathematicians who claim to >know C) can cause. I have been through the recovery programme so my >trauma is greatly reduced. But it is still there luring in the background. With all the insults that litter Christopher's posts, one must assume he hates C programmers. I find this whole C++ purity argument specious. |
| Lynn McGuire <lmc@winsim.com>: Mar 13 11:33AM -0500 > Brian > Ebenezer Enterprises > http://webEbenezer.net For processing queries on my webserver. All of my server side apps are written in C++. Lynn |
| ram@zedat.fu-berlin.de (Stefan Ram): Mar 13 01:35AM >Why use a language with less options? Think about this question! (What was the lesson learned from PL/I? A new generation has grown that already forgot ...) |
| ram@zedat.fu-berlin.de (Stefan Ram): Mar 13 03:00PM >Do note that VB.net is a half decent language, but VB up till version 6 >or most forms of VBA are so buggy and badly documented, I would advice to >learn C++ instead. I give courses in both VBA and C++ (both during the recent months). I teach adults without any required previous knowledge. Unfortunately, for many of them, learning programming is very hard. I can observe that, with VBA, they are better motivated (because they already use Office and know what they want to do with VBA) and they get more sense of achievement earlier, because at the end of a short beginner's class, they already can write GUI software in VBA. In C++, I do not teach GUI programming because I only teach the language and its standard library in my courses, and, moreover, GUI programming would still be too difficult for the beginner's course in C++. So for a beginner with average previous knowledge, I do recommend VBA. VBA C++ Yes No Retrieve Web pages with the standard library (WTSL) Yes No Read Directories of the file system WTSL Yes No Build GUIs WTSL Yes No Easily work with text documents WTSL Yes No Easily work with spreadsheets WTSL Yes No A standard IDE with a debugger Yes No A simple REPL (immediate windows) VBA (immediate window) ? "Hello, World" C++ #include <iostream> int main() { ::std::cout << "Hello, World" << "\n"; } I have the impression that the majority of the students in my VBA course at the end of the beginner's course already have reached the point where they can use the language productively in their lives, while some students in my C++ courses might never reach that point. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment